libtrash in fedora Core 5

Ian Burrell ianburrell at
Sat Jan 21 05:42:07 UTC 2006

On 1/20/06, Ola Thoresen <redhat at> wrote:
> 2006-01-20 Ian Burrell <ianburrell at> wrote
> >
> > I realized recently is that instead of changing the behavior of the rm
> > command and unlink, we need a new command, trash.  The 'trash' command
> > would work just like 'rm' but would send the file to the trash instead
> > of unlinking it.  Then people and scripts could use the new command
> > instead of rm when they want the ability to get their files back.
> >
> The problem is - if you can even remotely imagine that you might want to
> get the files back in any possible future, why would you delete it in
> the first place?
> If you think there is any possibility that you might want the file back,
> you could just as well use 'mv' to get the files out of your way.
> The problem is when you delete a file _because_ you are _sure_ you will
> never need it again - and you later realize you made a mistake.

A move is exactly what trash on the desktop or as a command does.  To
the first approximation, alias trash="mv --target-directory=~/.Trash".
 There is some more complicated stuff since different partitions have
separate trash directories to keep the mv a simple rename.

Most of the time people aren't certain they want something gone. 
Programs can be certain they never want that temp file again so having
an unlink that disappears the file is a good thing.  Or people can be
certain they don't ever want that 4 GB DVD image or at least don't
want to waste storing it in the trash.  Which is why the desktop
offers a Delete command that makes it go away.

> I am not sure if libtrash is the "right" solution, but any other
> solutions that in reality just replicates options you already have are
> really no solutions at all.

The only other option would be to have a filesystem which can restore
all deleted files (at least until they are overriden) or old versions.
 But versioned or log structured file systems are pretty different.

 - Ian

More information about the fedora-devel-list mailing list