deleted files no longer in trash but .caltrash

[Quoth]

Originally Posted by ownedbycats

On Windows, you have to copy it out of the trash and then add it.

Yes. So a Calibre bin solves more than one issue. Restore doesn't work on any OS and the trash/bin/refuse works differently on different OSes anyway.

[ownedbycats]

And if the bin is disabled entirely you're screwed!

[lostinlodos]

Originally Posted by Quoth

It is, and "restore" from system trash will fail on Mac, Windows and Linux because the Database won't know and the metadata will be missing. You had to "Add" the book from the trash as if it was in a download folder.

Restore on MacOS absolutely does work. It places the rules right back in the calibre folder where they came from.

Now you may be confusing delete from library and delete from system (not sure the exact term, I’m not in front of my computer)…
If so, yes, recovering from system trash does not send it back to the program.

But when I actively send a file to system trash by choice, and it suddenly no longer is going to system trash but preserving files I chose to delete: that’s a flaw.
By design or not, the old system worked just fine for competent users.

I hope calibre doesn’t join the cliff-dice other big programs are doing: dumbing down and removing useful options for stupid people.

Delete should be delete. We had two options and both worked. Deleting the entry in the program, and deleting the file from the system —to trash.

[lostinlodos]

Originally Posted by Quoth

Yes. So a Calibre bin solves more than one issue. Restore doesn't work on any OS and the trash/bin/refuse works differently on different OSes anyway.

I have yet to see a stable OS with a faulty trash system.
Restore, recover, return, put back….
It works on every major OS.

I welcome any screen shots or video showing otherwise: it doesn’t happen aside from major hard drive issues or malware.

[ownedbycats]

Originally Posted by lostinlodos

Restore on MacOS absolutely does work. It places the rules right back in the calibre folder where they came from.

It won't be restored to the Calibre database.

[theducks]

Originally Posted by lostinlodos

I have yet to see a stable OS with a faulty trash system.
Restore, recover, return, put back….
It works on every major OS.

I welcome any screen shots or video showing otherwise: it doesn’t happen aside from major hard drive issues or malware.

Did you look at how Calibre did things beneath the skirts?
It uses the file system instead of a BLOB to store the media portions.

Delete inside Calibre removes both the media and the DB entries to that.
Using the OS only puts the media into the old location. The DB entry is still gone

[Quoth]

Originally Posted by lostinlodos

I have yet to see a stable OS with a faulty trash system.
Restore, recover, return, put back….
It works on every major OS.

I welcome any screen shots or video showing otherwise: it doesn’t happen aside from major hard drive issues or malware.

It doesn't work at all, ever, with any application on any OS that uses a file for content but all the management and metadata is in a database. Few databases use an internal "binary blob" column, most store large data as files and the column has the file name relative to the database's media folder.

Access, MSDE, MS SQL, dBaseII, MariaDB, MySQL, Oracle, DB2, SQLight: The designers will put "imported" files (Word, ebooks, archive scans, images etc in a folder/directory that's logically private. A binary blob approach of storing the imported data inside the actual database engine works badly for ebooks, images, scanned documents and MS Office files or similar. They are too large and varied in size. It's not impossible, but works poorly.

In such cases you have to restore the file (from trash/bin/recycle) to somewhere outside the database's file system and freshly "add / import". So Calibre has added a private application specific "trash can" which I assume somehow also stores the metadata in a companion file.

[theducks]

Originally Posted by Quoth

In such cases you have to restore the file (from trash/bin/recycle) to somewhere outside the database's file system and freshly "add / import". So Calibre has added a private application specific "trash can" which I assume somehow also stores the metadata in a companion file.

I peeked
It stores a folder with the {id}, inside is the books(s) and metadata.opf.
??no cover

[ownedbycats]

On at least Windows/NTFS, the folder is also hidden by default.

[DNSB]

Originally Posted by lostinlodos

Restore on MacOS absolutely does work. It places the rules right back in the calibre folder where they came from.

An interesting but flawed belief. I tried that on a MacOS VM with calibre 6.10. I deleted a book and used the right click menu Put Back option. Sadly, calibre knew nothing about the book being restored from the trash so the database was not consistent with the library. Yes, the book was back in the calibre library folder and I could run Check library and go through the whole procedure. Sadly, that takes a lot more time than restoring from calibre's trash.

[BetterRed]

Originally Posted by DNSB

. . .

Sadly, that takes a lot more time than restoring from calibre's trash.

I can attest to that.

Earlier this week I inadvertently deleted a 'book' from my Media library, which included a 1.3 gigabyte video 'clip'. Restore from .caltrash was done & dusted in < 2 seconds. This was on a spinning rust drive. Previously, because of my miserly Recycle bin settings, I would have had to restore from backup - and that would have taken several minutes to 'copy' the 1.3GB file from a USB drive.

My only gripe with the new regime is: Why did it take so long? Far as I can tell it doesn't use any calibre or platform features that didn't exist decades ago.

BR

[sile2001]

There seriously needs to be a way to disable the .caltrash "feature". I've read the threads and posts arguing for why it exists, and I'm sure for a lot of people, it's just fine.

It fails hard for people who keep their libraries on a network share. With this change, I can no longer delete books from my library. Any attempt to do so results in an error similar to the following:

calibre, version 6.18.1
ERROR: Unhandled exception: <b>OSError</b>:[WinError 50] The request is not supported: 'X:\\books\\.caltrash'

calibre 6.18.1  embedded-python: True
Windows-10-10.0.19045-SP0 Windows ('64bit', 'WindowsPE')
('Windows', '10', '10.0.19045')
Python 3.10.1
Windows: ('10', '10.0.19045', 'SP0', 'Multiprocessor Free')
Interface language: None
Successfully initialized third party plugins: Gather KFX-ZIP (from KFX Input) (1, 51, 0) && DeDRM (7, 2, 1) && Package KFX (from KFX Input) (1, 51, 0) && KFX metadata reader (from KFX Input) (1, 51, 0) && KFX Input (1, 51, 0)
Traceback (most recent call last):
  File "calibre\gui2\actions\delete.py", line 488, in delete_books
  File "calibre\gui2\actions\delete.py", line 459, in do_library_delete
  File "calibre\gui2\library\models.py", line 466, in delete_books_by_id
  File "calibre\db\cache.py", line 85, in call_func_with_lock
  File "calibre\db\cache.py", line 2082, in remove_books
  File "calibre\db\backend.py", line 2140, in remove_books
  File "calibre\db\backend.py", line 2009, in ensure_trash_dir
OSError: [WinError 50] The request is not supported: 'X:\\books\\.caltrash'

Adding new features is great. But it's not at all necessary to prevent people from disabling this feature.

[Quoth]

You aren't supposed to use Calibre on a Network share. Madness. Read the manual.
I only use the network to backup.
I only run network aware applications to a network. Otherwise I use a local copy of the files.

[sile2001]

Originally Posted by Quoth

You aren't supposed to use Calibre on a Network share. Madness.

Madness. To think it normal that a somewhat widely-used application in 2023 doesn't support a mechanism that has been in Windows since 1995, Linux since the mid-to-late 90's (at least), and OSX since 2002. Got it.

[ownedbycats]

Originally Posted by sile2001

Madness. To think it normal that a somewhat widely-used application in 2023 doesn't support a mechanism that has been in Windows since 1995, Linux since the mid-to-late 90's (at least), and OSX since 2002. Got it.

Network filesystems are simply too limited for the types of thing Calibre does with file locking and the such. SQLite especially:

https://www.sqlite.org/whentouse.html

SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

https://www.sqlite.org/useovernet.html

This simple, "remote database" approach is usually not the best way to use a single SQLite database from multiple systems, (even if it appears to "work"), as it often leads to various kinds of trouble and grief.

https://stackoverflow.com/questions/...-network-share

My experience of file based databases (i.e. those without a database server process), which goes back over twenty years, is that if you try to share them, they will inevitably eventually get corrupted. I'd strongly suggest you look at MySQL again.

And please note, I am not picking on SQLite - I use it myself, just not as a shared database.