libtrash - a trash can for GNU/Linux.

What this page is about:

This is the homepage of libtrash, the shared library which, when preloaded, implements a trash can under GNU/Linux. Through the interception of function calls which might lead to accidental data loss libtrash effectively ensures that your data remains protected from your own mistakes.

libtrash was written by Manuel Arriaga and is available as free software: it is distributed under the terms of the GPL.

Version 3.7 can be downloaded from here.

To ask questions, suggest modifications or report bugs just email me (email address found at the bottom of the page).

Important note regarding web browsers based on Mozilla Firefox and Google Chrome: On several systems Mozilla Firefox, Google Chrome and browsers based on their code fail to start when libtrash is enabled. The easiest work-around is to disable libtrash for these browsers. Do so by starting Chrome with the command line "LD_PRELOAD= google-chrome" and Firefox with "LD_PRELOAD= firefox" (simply adjust the command accordingly for the other browsers). You can bind this command (if necessary by placing it in a one-line bash script file by itself) to whatever GUI icon or hotkey combination you use to start that browser. You may also modify your desktop file to include LD_PRELOAD= on the Exec= line.

News: (2021/Feb/21)

This release adds neither features nor bug fixes, but thanks to Peter Hyman libtrash now builds using autotools rather than clunky build scripts!

News: (2020/Aug/04)

This release fixes a latent bug that had been hiding in one of the libtrash build scripts and that recently manifested itself on systems with long(er) symbol names.

News: (2020/May/08)

This release brings an additional feature: users can now define a file size limit above which no files will be deleted. (My thanks to Peter Hyman for submitting a patch!)

News: (2018/Mar/25)

Four years since the last tweak, version 3.4 has been released! This new version fixes a misbehavior due to a new feature in GNU libc's open() functions as well as a bug in the way we handle file descriptors with a value of 0. (My thanks to Felix Becker for his report and help in tracking down the faulty code.)

News: (2014/Jun/08)

After more than 6 years since the last tweak, version 3.3 has been released! Two functions were renamed in order to avoid symbol clashes which some users of Audacious plugins were experiencing. (My thanks to Kamil Dudka for sending me a patch.)

News: (2008/Jan/23)

Updated the configuration script so that users are notified if a more recent version of Python needs to be installed (rather than producing a cryptic error message). There is NO reason for existing users to upgrade to this version.

News: (2007/Dec/27)

Updated the so that the symbol version used for each wrapped GNU libc function is that identified with "@@" in the output of 'readelf -s [path to lib]'.

News: (2007/Dec/4)

Fixed several bugs; changed the way we get pointers to GNU libc functions (now it should work for everyone); support for the "ATFILE" family of functions is now decided automatically at compile-time (rather than having the user experiment with the setting); added a compile-time check for a working /proc filesystem. Also, now Python is required to install (not to run) libtrash.

News: (2007/Dec/2)

Fixed a minor bug (only present when compiled in DEBUG mode) and removed an earlier 'fix' which was proving problematic for some.

If you were using libtrash before, please notice that there has been a small change to the default configuration: '/media' is now included in the default list of removable media mount points (together with '/mnt'), and therefore any files residing underneath it will not be saved by libtrash (unless you edit the config file!).

News: (2007/May/6)

Released version 2.8! Fixed a small bug introduced in the last version; I had forgotten to replace a call to log10() although we no longer link against the math library.

News: (2007/May/4)

Released version 2.7! This version includes a performance fix by Jacek Sliwerski which keeps libtrash from significantly slowing down as you repeatedly remove the same file.

News: (2007/Feb/18)

Released version 2.6! Only users of GNU libc 2.5 need to upgrade, nobody else needs this. ('This' refers to wrappers for a set of new functions only available in the most recent GNU libc: unlinkat(), renameat(), openat() and their 64-bit variants.)

News: (2006/Oct/26)

Released version 2.5! Reimplemented build_absolute_path() so that it correctly handles paths to inexistent file system objects.

News: (2005/Sep/24)

Released version 2.4! Implements a work-around needed to avoid trouble due to a undocumented "feature" of GNU libc.

News: (2004/11/07)

Released version 2.3, which fixes a bug in handling function calls with a NULL pointer.

News: (2003/12/07)

Released version 2.2, which fixes a bug in the string handling code.

News: (2003/06/25)

Released version 2.1, which fixes a bug in the path handling code.

News: (2003/03/05)

Released version 2.0. libtrash now has an "ignore regular expression" (IGNORE_RE) feature, which allows the user to provide a regular expression describing file names which will be ignored.

News: (2003/02/26)

Released version 1.9. This new version fixes a serious bug which made libtrash enter an infinite loop when asked to remove files with names starting with multiple dots.

News: (2003/02/04)

Just released version 1.8. This version adds a simple check which prevents libtrash from saving files with a null byte count. This will reduce the number of worthless lock files in the user's trash can.

News: (2003/01/07)

Just released version 1.7, which includes two small fixes to the cleanTrash script and the Makefile contributed by Frederic Connes.

News: (2002/12/06)

Just released version 1.6. It adds a new feature, USER_TEMPORARY_DIRS, which can be used by system administrators to define a list of temporary dirs relative to the users' home directories. See documentation for more details. No bug fixes.

News: (2002/11/06)

Version 1.5 has been released. It fixes two bugs: one memory leak and a bug which kept libtrash from completely reading personal configuration files if they contained blank lines.

News: (2002/10/13)

Version 1.4 has been released. It fixes a bug in the creation of replacement files when open() and open64() are being intercepted so that those files always have the same permissions as the original ones they are replacing.

News: (2002/08/20)

Version 1.3 has been released, featuring an alternative cleanTrash script.

News: (2002/06/08)

Just released version 1.2. Changed a part of the code so that the new feature, UNCOVER_DIRS, works perfectly: typing "UNCOVER_DIRS=/usr/" now produces the same effect as "UNCOVER_DIRS=/usr". This is handy because shell auto-completion will add that trailing slash for you if you just type "UNCOVER_DIRS=/u[Tab]". More importantly, there is now an EXCEPTIONS variable which allows you to list files which, although residing in one of the UNREMOVABLE_DIRS, shouldn't be protected by libtrash. This allows mount/umount to correctly handle their lock file (/etc/mtab~) while libtrash is running and /etc is listed in UNREMOVABLE_DIRS.

News: (2002/06/02)

Just released version 1.1, which allows to you to temporarily "uncover" your trash can by simply listing it in UNCOVER_DIRS at the command line.

News: (2002/06/01)

A few days ago I released version 1.0. After doing so, I installed KDE 3.0.1 and found out that the GNU libc bug I mentioned below also causes KMail to crash if you are using libtrash. To overcome that, you'll need to recompile GNU libc with the patch included in the tarball.

News: (2002/04/04)

It has been confirmed: mutt crashed under libtrash due to a GNU libc bug. You can download a patch against glibc-2.2.5 from here.

News: (2002/04/03)

Apparently, the problem I describe below might be caused by GNU libc itself.

News: (2002/04/01)

libtrash-0.9 makes any recent version of mutt crash when you try to sync your mailbox. The segmentation fault occurs inside GNU libc, after mutt calls ftell(). I am unable to trace down this bug, and would welcome any help.

Manuel Arriaga - Email me at marriaga followed by @ stern . nyu . edu