Strange - and dangerous - behavior - FFS 14.7

[mabian]

Hello, I found this issue, for me it's quite unexpected and also dangerous because it can easily cause file loss.

I compare two folders with "content" options, then I select the "=" button to only see the files that were found perfectly equal.

I select some of them (shift or ctrl-click) then press "del" key.

The delete confirmation dialog shows only the selected files and their count.
But, then, proceeding, all of the files are deleted, regardless of the selection and the confirmation dialog.

Happened on Windows and Linux versions, FreeFileSync 14.7.

Thanks,
Mario

[xCSxXenon]

Just tested this and could not recreate the behavior. Any more specific details?

[mabian]

Happened again today... I had two folders with many identical files, and some files only on one of the two compared folders.

After content comparison, clicked the "=" button to show only the identical ones, then CTRL-A to select all the ones on one side (expecting only the equal files be selected - ie the ones shown), then "delete" (keyboard DEL key) and checked "delete permanently" instead of "Move to recycle bin".
Results of synchronization: everything in the involved folder was deleted, even the files that were not equal. Maybe CTRL-A is the key point here?

[Zenju]

This is the old usability issue that folders are also considered "=" and are part of the list.

[mabian]

Ouch... what can be done to prevent this kind of accident then?

This is really prone to cause file loss...

[xCSxXenon]

This is the old usability issue that folders are also considered "=" and are part of the list.

This behavior makes no sense, then. The folders must be different since some files only exist on one side, thus using the filters to only show '=' line items should not expose the parent folder at all as they aren't equal. Am I missing something?

[mabian]

This is the old usability issue that folders are also considered "=" and are part of the list.

This behavior makes no sense, then. The folders must be different since some files only exist on one side, thus using the filters to only show '=' line items should not expose the parent folder at all as they aren't equal. Am I missing something?

That's my point too. If a parent folder is marked equal if just one of the files inside is equal then it's very very *Very* dangerous. And, for sure in the past I deleted accidentally several files due to this.

[Zenju]

"=" for folders is "shallow", i.e. the child items don't matter. As long as both sides exist and have the same name, they are "=", which means no sync action is required for the folder object.
Also from UX perspective users generally are interested to see what's different. For this reason "=" category is hidden by default, which includes folders.
So the logic is in fact consistent and emergent from the basic design principle of mapping difference categories to sync actions.

Using the "=" category to emulate a "move" by deleting one side manually is not a core scenario for a sync tool. This doesn't mean however that FFS shouldn't go out of its way to avoid accidental data loss even in this case. I just don't see a way that would fit neatly into the UI concept.

[mabian]

What if any delete action would *never* delete folders that aren't empty (unless explicitly or optionally specified)?
Wouldn't this fit?

[xCSxXenon]

"=" for folders is "shallow", i.e. the child items don't matter. As long as both sides exist and have the same name, they are "=", which means no sync action is required for the folder object.

Very wrong IMO. If I showed anybody on earth two folders, with completely different files inside, and said they are equal because the names are the same, I'd be called insane. Same if I said two folders weren't equal because they have different names, even if the files are equal inside. I do see the difference though.

Also from UX perspective users generally are interested to see what's different. For this reason "=" category is hidden by default, which includes folders.
So the logic is in fact consistent and emergent from the basic design principle of mapping difference categories to sync actions.

Using the "=" category to emulate a "move" by deleting one side manually is not a core scenario for a sync tool. This doesn't mean however that FFS shouldn't go out of its way to avoid accidental data loss even in this case. I just don't see a way that would fit neatly into the UI concept.

I agree. The opposite behavior would also cause a problem too. For example:
- A folder is displayed as different because there are new files on one side
- A user is only showing differences
- The user selects all (CTRL-A) items on that side to remove them
- Deleting the selection also deletes the parent folder since the folder is not equal as specified in line 1, and it displayed in the comparison

Honestly the only solution I see, in my tired state, is to not display folders in the comparison results at all, unless it is for creating or deleting it. It could be selectable only in the overview pane in the bottom-left if there are contents inside. Or only displayed in the comparison if all filters available are enabled. Or only show if all items inside are being displayed according to the enabled filters. Just tossing some ideas out

[mabian]

If you don't display folders in the comparison, you can't right click "exclude temporarily", which is quite convenient for me.

I simply think that file inside folders that are marked equal shouldn't be deleted, unless the files themselves are marked equal to their counterpart as well...

- Mario