A big motivation for this project was that I wanted something like trash-cli but that was a single static binary instead of a larger Python application (nothing wrong with Python, I just like static binaries).
I package trash-cli for Debian. Someone in the debian community once showed me some esoteric invocation of some existing xdg tools (that we almost certainly have installed) that did almost everything trash-cli does, but missed something crucial (probably restore, haha). I wish I could remember what it was.
My original plan for this project was more or less that; patching together various standard commands using Bash. But this got clunky very quickly so I gave up on writing it in Bash and switched to D.
A big motivation for this project was that I wanted something like trash-cli but that was a single static binary instead of a larger Python application (nothing wrong with Python, I just like static binaries).
You can probably compile trash-cli into a static binary using Nuitka and its --onefile option assuming all the dependencies play nicely. If you run Nuitka within a conda environment you can get all the C dependencies statically compiled in, too. There are downsides to doing this, like the binary can get pretty large and compile times can be multiple minutes. I am still happy you made this project, though.
Only tangentially related: I always thought it would be nice if filesystems would use free space for deleted files much like snapshots and reclaim space by removing the oldest files when needed. This would give users a safety net by making good use of free disk space. Is any operating system providing something like this?
Pleased to hear someone else is eager for this! I’ve often thought it an oversight that filesystems treat “delete” as such a destructive operation when really it doesn’t need to be. As you mention, we do get part of the way there with snapshots, particularly on ZFS.
I realise that there are speed issues related to fragmentation and complexity in terms of finding a free block on a disk with less real free space. Both of these are less of a concern on SSD though.
Having an “IsDeleted” field on rows in a SQL table is not an uncommon pattern, would be great to have this equivalent for a filesystem.
Not discovered any existing filesystems or operating system that does this, but would love to see it!
That’s more or less what FAT did. Deleting a file was accomplished by just zeroing the first character of the filename, the file was only overwritten when you needed the space. The undelete tool for DOS would just ask you to fill in the first letter of the filename for the restore. Log-structured filesystems typically get this kind of almost for free: a delete operation is just an entry in the log saying that the next GC phase is allowed to reclaim the blocks. You could imagine adding a generational GC that would not actually reclaim blocks until they’d been marked as garbage for multiple cycles.
On an inode-based filesystem you could probably do something similar by just adding a hard link to deleted files into a hidden trash directory in a circular buffer and adding files from this back to the free list when space is constrained.
Amoeba’s filesystem (I think) never really did deletion, it was predicated on the idea that files grew more slowly than available storage (which wasn’t really true then but probably is now) and so it was an append-only log. I think they did something different for ephemeral things. Another system (or possibly Amoeba and I’m getting them mixed up) had no explicit delete at all and just GC’d files that haven’t been accessed recently. Apparently users just ended up running cron jobs that touched every file in their home directory every night.
I know Sprite had a log-structured file system (maybe even the first?) and leaned heavily on client-side caching of normally-remote files with IIRC fairly aggressive deletion of local cached copies.
Files-11 on VMS did automatic file versioning: when you wrote to a file, a new version was created and versions older than the limit were removed. You had to explicitly specify a version when deleting, IIRC (there were facilities for purging all old version as well).
I feel like not enough people appreciate AppleScript. Sure, it’s pretty obtuse at first glance, but it’s well documented and highly discoverable. In Script Editor.app, ⇧⌘L opens the library, documenting all the classes, elements, and properties of built in apps and services. You can select and run individual lines to poke at values, or use the REPL (osascript -i):
>> tell application "Notes" to get properties of first note
=> {container:folder id "x-coredata://UUIDUUID-UUID-UUID-UUID-UUIDUUIDUUID/ICFolder/p2" of application "Notes", class:note, password protected:false, modification date:date "Thursday, September 9, 2021 at 1:26:13 PM", creation date:date "Thursday, September 9, 2021 at 1:18:57 PM", shared:false, body:"<div><h1>Discoverability Example for Lobste.rs</h1></div>
<div><br></div>
<div>The contents will show up in the result!</div>
", id:"x-coredata://UUIDUUID-UUID-UUID-UUID-UUIDUUIDUUID/ICNote/p490", name:"Discoverability Example for Lobste.rs", plaintext:"Discoverability Example for Lobste.rs
The contents will show up in the result!"}
Cool, a static binary seems like a good feature to have for this kind of tool.
I also was slightly dissatisfied with trash-cli and wrote an alternative, but in Python again: https://github.com/alphapapa/rubbish.py It’s nothing fancy, but it’s worked well for me.
trash-d: A near drop-in replacement for rm that uses the trash bin
also
Windows won’t work at all, and MacOS probably won’t either. There are no plans for support of either platform.
Maybe not so drop-in after all…
Not a big fan of Node but maybe https://github.com/sindresorhus/trash could be used as an inspiration. Ironically, sindresorhus/trash states that their Linux support is not that good.
I intentionally chose to only support platforms conforming to the FreeDesktop trash specification since that covered all the systems that I personally cared about (I don’t own a Mac or use rm on Windows).
I should really update the README though, since I am totally open to supporting those platforms, if it can be done in a way that doesn’t cause other problems.
Also I hadn’t heard of sindresorhus/trash, thanks for sharing it! Their platform-specific tools could be very enlightening.
EDIT: I updated the README to reflect my opinion on MacOS and Windows support better, along with some other information and links to similar projects like the one above.
I just use a short script which prompts me (once, with a list) if I’m trying to remove 2+ files. That handles all my use cases with file globs picking up more files than I intended.
Quite nice! I love little tools like this; I’ve had
trash-clialiased tormfor a long time and never regretted it.A big motivation for this project was that I wanted something like
trash-clibut that was a single static binary instead of a larger Python application (nothing wrong with Python, I just like static binaries).Also I wanted to actually mirror the semantics of
rmas much as possible, sincetrash-putdoes not and it is not recommended that you alias it.I package trash-cli for Debian. Someone in the debian community once showed me some esoteric invocation of some existing xdg tools (that we almost certainly have installed) that did almost everything trash-cli does, but missed something crucial (probably restore, haha). I wish I could remember what it was.
My original plan for this project was more or less that; patching together various standard commands using Bash. But this got clunky very quickly so I gave up on writing it in Bash and switched to D.
You can probably compile trash-cli into a static binary using Nuitka and its
--onefileoption assuming all the dependencies play nicely. If you run Nuitka within a conda environment you can get all the C dependencies statically compiled in, too. There are downsides to doing this, like the binary can get pretty large and compile times can be multiple minutes. I am still happy you made this project, though.Only tangentially related: I always thought it would be nice if filesystems would use free space for deleted files much like snapshots and reclaim space by removing the oldest files when needed. This would give users a safety net by making good use of free disk space. Is any operating system providing something like this?
Pleased to hear someone else is eager for this! I’ve often thought it an oversight that filesystems treat “delete” as such a destructive operation when really it doesn’t need to be. As you mention, we do get part of the way there with snapshots, particularly on ZFS.
I realise that there are speed issues related to fragmentation and complexity in terms of finding a free block on a disk with less real free space. Both of these are less of a concern on SSD though.
Having an “IsDeleted” field on rows in a SQL table is not an uncommon pattern, would be great to have this equivalent for a filesystem.
Not discovered any existing filesystems or operating system that does this, but would love to see it!
That’s more or less what FAT did. Deleting a file was accomplished by just zeroing the first character of the filename, the file was only overwritten when you needed the space. The
undeletetool for DOS would just ask you to fill in the first letter of the filename for the restore. Log-structured filesystems typically get this kind of almost for free: a delete operation is just an entry in the log saying that the next GC phase is allowed to reclaim the blocks. You could imagine adding a generational GC that would not actually reclaim blocks until they’d been marked as garbage for multiple cycles.On an inode-based filesystem you could probably do something similar by just adding a hard link to deleted files into a hidden trash directory in a circular buffer and adding files from this back to the free list when space is constrained.
Amoeba’s filesystem (I think) never really did deletion, it was predicated on the idea that files grew more slowly than available storage (which wasn’t really true then but probably is now) and so it was an append-only log. I think they did something different for ephemeral things. Another system (or possibly Amoeba and I’m getting them mixed up) had no explicit delete at all and just GC’d files that haven’t been accessed recently. Apparently users just ended up running cron jobs that touched every file in their home directory every night.
I know Sprite had a log-structured file system (maybe even the first?) and leaned heavily on client-side caching of normally-remote files with IIRC fairly aggressive deletion of local cached copies.
Files-11 on VMS did automatic file versioning: when you wrote to a file, a new version was created and versions older than the limit were removed. You had to explicitly specify a version when deleting, IIRC (there were facilities for purging all old version as well).
Basic implementation for MacOS. Works on files and folders. Not a drop in replacement for
rm.I feel like not enough people appreciate AppleScript. Sure, it’s pretty obtuse at first glance, but it’s well documented and highly discoverable. In Script Editor.app, ⇧⌘L opens the library, documenting all the classes, elements, and properties of built in apps and services. You can select and run individual lines to poke at values, or use the REPL (
osascript -i):Cool, a static binary seems like a good feature to have for this kind of tool.
I also was slightly dissatisfied with
trash-cliand wrote an alternative, but in Python again: https://github.com/alphapapa/rubbish.py It’s nothing fancy, but it’s worked well for me.also
Maybe not so drop-in after all…
Not a big fan of Node but maybe https://github.com/sindresorhus/trash could be used as an inspiration. Ironically, sindresorhus/trash states that their Linux support is not that good.
I intentionally chose to only support platforms conforming to the FreeDesktop trash specification since that covered all the systems that I personally cared about (I don’t own a Mac or use
rmon Windows).I should really update the README though, since I am totally open to supporting those platforms, if it can be done in a way that doesn’t cause other problems.
Also I hadn’t heard of sindresorhus/trash, thanks for sharing it! Their platform-specific tools could be very enlightening.
EDIT: I updated the README to reflect my opinion on MacOS and Windows support better, along with some other information and links to similar projects like the one above.
I just use a short script which prompts me (once, with a list) if I’m trying to remove 2+ files. That handles all my use cases with file globs picking up more files than I intended.