[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1440: Concerning delete-by-moving-to-trash on free systems
From: |
Tassilo Horn |
Subject: |
bug#1440: Concerning delete-by-moving-to-trash on free systems |
Date: |
Fri, 28 Nov 2008 22:58:44 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
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