Chong Yidong wrote:
> Hi David,
> 
> Could you take a look at Bug#5436?  Thanks.
> 
>> I have `delete-by-moving-to-trash' enabled.  When I delete a directory
>> with `M-x delete-directory' or using `D' in dired on a directory and say
>> that I want to delete it recursively, the freedesktop trashcan contains
>> entries for each file deleted, and not only one entry for the whole
>> directory.
>>

Please find attached small* patch that should address this (and Bug#3353).

* Given the recursively data devouring area it's in, please examine 
extra-carefully all the same...

delete-directory:

  is adjusted to call move-file-to-trash with the expectation 
move-file-to-trash can move non-empty directories to trash - which was 
already true, mostly, since it just called rename-file on them, and 
/that/ already silently worked ...so long as the source and destination 
were on the same device.

I believe, but haven't actually tested, that w32's override 
system-move-file-to-trash already works for non-empty directories too.


rename-file:

is adjusted to call copy-directory then delete-directory to emulate 
cross-device directory renames as proposed under Bug#3353

Note that rename-file's existing behaviour when FILE and NEWNAME (from 
and to) were both directories seemed problematic to me, so I adjusted it:

. existing behaviour:

Rather than moving directory FILE within directory NEWNAME, as happens
with the existing code if FILE is a regular file and NEWNAME a directory 
- if directory NEWNAME is empty, directory FILE becomes a directory 
NEWNAME, and if  NEWNAME isn't empty, the operation fails.

That means emacs without this patch acts more like raw C rename() for 
directory-to-directory, yet like shell mv (except "mv -T") for 
regular-file-to-directory.

. new behaviour:

I thought that was plain inconsistent, so made it move directory FILE 
into directory NEWNAME if NEWNAME exists and is a directory in the 
intra-device case.  That also means less messing about in the 
inter-device case to make it match the intra-device case, since 
copy-directory has 
copy-within-destination-if-destination-is-an-existing-directory
semantics. However, it is possible (though IMO unlikely) that may break 
something somewhere, so I note doing it the other way and making the 
inter-device behaviour emulate the unpatched intra-device 
directory-directory C-rename()-like behaviour would be possible - seems 
less friendly to me though.