GNU bug report logs -
#1440
23.0.60; delete-by-moving-to-trash loses data
Previous Next
Full log
View this message in rfc822 format
David De La Harpe Golden <david <at> 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
This bug report was last modified 15 years and 151 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.