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

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

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

[Tassilo Horn]

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

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

[David De La Harpe Golden]

 > I'd propose to let-unbind backup-directory-alist when making backups
 > for deleted files.

That seems sensible/necessary.
Though I think that maybe backup and trashing code paths should just be 
decoupled to avoid ongoing problems - i.e. have  move-file-to-trash just 
not use find-backup-file-name. What happens when someone next changes 
the backup-file subsystem, or a user locally patches it?  fallback 
trashing silently breaks, of course, surprise! There's also the minor 
point that find-file-name handlers can't distinguish a fallback trash 
operation from a backup operation at present and might conceivably do 
the wrong thing.

And of course, all this is about fixing the fallback trashcan, which as 
already noted doesn't correspond to the free desktop trashcan. It 
probably isn't a proper  implementation of the macosx trashcan really 
either (should probably really be  using the relevant system trash api 
on that platform , which appears to be (though I'm not a  macosx 
programmer, just cursory google search) NSWorkspaceRecycleOperation  or 
maybe FSMoveObjectToTrashSync)