From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Werner LEMBERG Newsgroups: gmane.emacs.devel Subject: Re: Why @#! is not Emacs using the Recycle bin on w32? Date: Sat, 30 Aug 2008 20:37:55 +0200 (CEST) Message-ID: <20080830.203755.13026242.wl@gnu.org> References: <48B7288E.3040503@gmail.com> <20080829.120151.161624313.wl@gnu.org> <48B7F96C.5030908@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220167628 20472 80.91.229.12 (31 Aug 2008 07:27:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2008 07:27:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: lennart.borgman@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 09:28:02 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KZhLu-0004uU-5j for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 09:28:02 +0200 Original-Received: from localhost ([127.0.0.1]:36572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZhKv-0007tZ-9e for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 03:27:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZhKq-0007tI-Eq for emacs-devel@gnu.org; Sun, 31 Aug 2008 03:26:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZhKp-0007sS-4K for emacs-devel@gnu.org; Sun, 31 Aug 2008 03:26:56 -0400 Original-Received: from [199.232.76.173] (port=54152 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZhKo-0007sO-R6 for emacs-devel@gnu.org; Sun, 31 Aug 2008 03:26:54 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:23259) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZhKo-0001Ed-41 for emacs-devel@gnu.org; Sun, 31 Aug 2008 03:26:54 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.187]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZhKb-0004Gz-Dp for emacs-devel@gnu.org; Sun, 31 Aug 2008 03:26:41 -0400 Original-Received: from localhost (i577A0ECD.versanet.de [87.122.14.205]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1KZhKN4AiN-0008Bw; Sun, 31 Aug 2008 09:26:28 +0200 In-Reply-To: <48B7F96C.5030908@gmail.com> X-Mailer: Mew version 5.2.53 on Emacs 23.0.50.2 / Mule 5.0 (SAKAKI) X-Provags-ID: V01U2FsdGVkX19+8VYLIwNGmUPQuJR5HFqGaO646sfq8MAPuMQ yx6IgKvhdSQsLyJeGKlkWUcZW4rrw+zvd07iu4FmprYgWDgoGn Mot9lBcY0woA2ltH46+jg== X-detected-kernel: by mx20.gnu.org: Linux 2.6? (barebone, rare!) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103300 Archived-At: > > I use the `libtrash' library very successfully to prevent > > accidental data loss (since I mainly work on the console which > > never uses the trash folder of the GUI). > > Sounds interesting. At what level does it interface? At the lowest one. Here some snippets of the README: libtrash is a shared library which, when preloaded, will intercept calls to a series of GNU libc functions and make sure that, if an attempt to destroy certain files is made, these won't be permanently destroyed but rather moved to a "trash can". It also allows the user to mark certain directories as "unremovable", which means that calls to functions which would result in the loss of files under these directories will always fail, leaving those files untouched in their original locations. (This last feature is meant as a higher-level substitute for ext2fs' "immutable" flag for use by those of us who rely on other file systems. An important difference is that libtrash allows non-privileged users to use this with their personal files.) The GNU libc functions which can be overriden/"wrapped" are - unlink() / unlinkat(); - rename() / renameat(); - fopen() / fopen64(); - freopen() / freopen64(); - open() / openat() / open64() / openat64(). You can individually enable / disable each of these "protections"; by default, only calls to the first two functions are intercepted. [...] libtrash recreates the directory structure of your home directory under the trash can, which means that, should you need to recover the mistakenly deleted file /home/user/programming/test.c, it will be stored in /home/user/Trash/programming/test.c. If you have instructed libtrash to also store copies of files which you delete in directories outside of your home dir (see libtrash.conf for details), they will be available under Trash/SYSTEM_ROOT. E.g.: after deletion by the user joe, /common-dir/doc.txt will be available at /home/joe/Trash/SYSTEM_ROOT/common-dir/doc.txt. I have a cron job which simply deletes files in the `Trash' directory older than 24 hours (using a script which comes with the libtrash library). Werner