Opened 10 years ago

Last modified 12 months ago

#5335 in-progress bug

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

Reported by: humdinger Owned by: jscipione
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/Development
Keywords: Cc: jstressman@…
Blocked By: Blocking: #8404, #9090, #12688
Has a Patch: no Platform: All

Description

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

Change History (7)

comment:1 by humdinger, 10 years ago

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

comment:2 by jstressman, 10 years ago

Cc: jstressman@… added
Summary: Can't delete a folder with same name as a trashed fileConflicts and inconsistencies when sending files and folders to the trash.

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?

comment:3 by luroh, 8 years ago

Blocking: 8404 added

comment:4 by humdinger, 7 years ago

Blocking: 9090 added

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

comment:5 by axeld, 2 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:6 by jscipione, 15 months ago

Owner: changed from nobody to jscipione
Status: assignedin-progress

comment:7 by waddlesplash, 12 months ago

Blocking: 12688 added
Note: See TracTickets for help on using tickets.