Conflicts and inconsistencies when sending files and folders to the trash.

[humdinger]

This is hrev35329.

If there's a file "foobar" already in the Trash, Tracker won't trash a folder also called "foobar".

Vice-versa is no problem, the to be trashed file is then renamed to "foobar copy". Same should be done with to be trashed folders.

Took me awhile before realizing why Tracker simply refused to delete a specific folder but did so with any other... :)

[humdinger]

Now, with hrev35922, the foobar folder can be deleted, but never appears n the trash.

[jstressman]

After humdinger mentioned this I did some further testing and we have even more inconsistent and bad behavior...

If you have a folder in the trash calling "Testing" and you then delete another folder called "Testing" it will be silently merged with the previous folder and any files inside that folder will silently overwrite the previous files regardless of their contents.

So if you have a "Testing" folder with a "Foobar" file in it that is 1mB of data... and you then delete a "Testing" folder with a file in it called "Foobar" that is 0 size, it will silently overwrite the previous file with the 0 size file.

If you then delete a folder called "Testing" with a folder called "Foobar" in it, with the other "Testing" folder with the "Foobar" file in it already in the trash, the new folder "Foobar" in the "Testing" folder will simply be silently discarded completely as in the behavior humdinger was talking about.

Should there be some kind of invisible means of indexing deletes by time or something that you wouldn't start piling up copies of copies, and instead have the files using their original names, with a "deleted on" date or something? That way there would be no issue with the name conflicts to begin with?

[humdinger]

(In #9090) Duplicate of #5335. Not sure it's an alpha4 blocker, seeing that it wasn't for alpha1, 2 and 3... :)