Hello nixers,
No this isn't a post trashing shell scripting.

Handling files on the command line is most of the time a non-reversable process, a dangerous one in some cases (Unix Horror Stories). There are tricks to avoid the unnecessary loss and help in recovering files if need be.

Quote:Users do not expect that anything they delete is permanently gone. Instead, they are used to a “Trash can” metaphor. A deleted document ends up in a “Trash can”, and stays there at least for some time — until the can is manually or automatically cleaned.

In this thread we'll list what ideas we have on this topic, novel or not so novel.

---

There's the usual aliasing of rm to mv into a specific directory, a trash can for the command line.
This can be combined with a cron job or timer that cleans files in this directory that are older than a certain time.

You can check the actual XDG trash documentation that goes into great details about what needs to be taken into consideration:
https://specifications.freedesktop.org/t...c-1.0.html

In $HOME/.local/share/Trash ($XDG_DATA_HOME/Trash) and usually at least split into two directories:

• files for the actual exact copy of the files and directories (including their permission, and they should not override if two have the same names)
  
• info, that contains the information about where and what name the deleted file had, in case it needs to be restored. And also the date it was deleted.
  

Another way to avoid loosing files is to keep backups of the file system. This can be done via a logical volume management be it included in the file system itself (ZFS, btrfs, etc..) or not.

So nixers, what's your command line trash, how do you deal with avoidable losses.

+1 for file system backups: ZFS, HAMMER and (to some extent) Venti are fantastic.
Not everyone has FreeDesktop stuff.

I never understood ZFS well.. To me it's like the openstack of file systems. Huge lot of features, nearly too much to be understood by the lambda sysadmin :)

Venti is awesome. It's pifs but actually usable! The thing is that it won't magically backup your filesystem. If I understand correctly, It keeps the data, but you have to keep track of the file indexes yourself (kind of like any filesystem, when you unlink(2), the data remains on disk. Venti just NEVER overwrites it).

I like the idea of using the FS has a way to prevent data loss, but you'll either need to take snapshots very often, or need some kind of version control implemented IN the FS directly.

(08-03-2019, 04:35 AM)z3bra Wrote: I like the idea of using the FS has a way to prevent data loss, but you'll either need to take snapshots very often, or need some kind of version control implemented IN the FS directly.

Indeed, it might be overkill for a single file but is quite useful, acting as a backup, in the case when multiple files are lost.

Maybe we should consider a new undo(2) syscall, which would undo the latest syscall! Afyer all, recreating an inode shouldn't be too hard.
Would that be possible? Are there any syscall that cannot be reverted?

kill(), probably.

These are the scripts I use to trash and "untrash" (remove from trash) files.
I set the $TRASH environment variable to $HOME/trash. I do not like the freedesktop convention on using .local/share

trash:

untrash: