bug#1440: Concerning delete-by-moving-to-trash on free systems

[David De La Harpe Golden]

> 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.)