[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1440: Concerning delete-by-moving-to-trash on free systems
From: |
David De La Harpe Golden |
Subject: |
bug#1440: Concerning delete-by-moving-to-trash on free systems |
Date: |
Fri, 28 Nov 2008 18:53:34 +0000 |
User-agent: |
Mozilla-Thunderbird 2.0.0.17 (X11/20081018) |
> Delete a directory foo which contains the files a and b recursively
> (from within dired). Then goto the trash-directory. Now foo, a and
> b are side by side.
Not 100% sure, but one guess: maybe dired is itself recursing into the
directory and deleting each file and then deleting the directory rather
than deleting the directory as one operation, thus causing the flattening.
> Now delete another file named a. This file is really deleted,
> because a already exists in trash. (Overwriting would be as bad as
> the current decision.)
Uh. Not that I'm a fan of the current builtin trashcan routine, but are
you sure that it is actually losing data?
The current emacs move-file-to-trash _should_ be generating alternative
in-trash names for files with clashing filenames with
find-backup-file-name , see function body.
Some GUI file managers may be treating the generated names as
"hidden" backup files due to the naming scheme - can you verify you
don't have "a.~1~" files in your ~/.Trash/ directory from the command
line? (My fd.o trashcan patch avoids using such filenames because turns
out several GUI file managers actually choke on them (see patch
commentary), btw, so if you've also adjusted your
unpatched-with-my-patch-emacs trash-directory to point to the sepcial
fd.o trashcan directory, then things will go, um, wronger.)
- bug#1440: Concerning delete-by-moving-to-trash on free systems,
David De La Harpe Golden <=