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

[Tassilo Horn <tassilo@member.fsf.org>]

David De La Harpe Golden <david@harpegolden.net> writes:

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

Yes, that's likely.  Anyway, I don't think that is what users would
expect and it makes recovery of deleted directories difficult.

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

I use dired.

> - can you verify you don't have "a.~1~" files in your ~/.Trash/
> directory from the command line?

Yes.  But I have

,----[ C-h v backup-directory-alist RET ]
| backup-directory-alist is a variable defined in `files.el'.
| Its value is 
| ((".*" . "~/.backupFiles/"))
`----

and indeed, there are the backup files.  I'd propose to let-unbind
backup-directory-alist when making backups for deleted files.  They
always should be in .Trash.

Bye,
Tassilo