Selecting "rename" in file conflict dialog overwrites parent directory if directory scan is still running

[jeth-ro]

Distribution

Gentoo

Package version

6.4.5

Frequency

Always

Bug description

For directories containing large numbers of files nemo can still be scanning for files after a user has initiated a copy/move which raises the file conflict dialog. If nemo has not yet scanned up to the conflicting file, the dialog is displayed partially initialized:

Note the presence of both "Replace" and "Rename" options at the same time. The entry box under the expander is blank. This state persist until file scanning catches up and file_list_ready_cb() gets called, at which point the dialog updates to it's usual and expected state.

If the user clicks "Rename" while the dialog is in this state (perhaps expecting a further prompt) then the empty string in the hidden entry box is applied to the current directory, resolving to the parent folder. Nemo then raises a conflict dialog to replace the parent folder with the file causing the initial conflict:

If the user then clicks "Replace" then exactly what the dialog says will happen occurs, destroying all content in the folder in question. Yes, it the conflict dialog is pretty explicit in what is about to happen, but please note:

• this is inconsistent with the filesystem layout; the folder "Camera" does not contain a folder named "Camera", it's the same folder.
• this is inconsistent with the operation initiated by the user and their mental model of what is happening
• if things are really grinding slow, then the second dialog can actually look just like the first

In that last case, it's way to easy to get burned by this. For example click Rename accidentally instead of Replace, after all it's almost the same word and they both usually appear in the same place. Dialog comes looking exactly the same, and wait! No! I meant Replace! boom

Steps to reproduce

1. Create a directory containing 10000+ files on slow media (e.g. old USB disk or SD card)
2. Duplicate a few (say 10) of the files to a separate location on a different storage device
3. Copy these files to clipboard in nemo
4. Browse to the device/folder the many files
5. Paste, wait for the half empty conflict dialog
6. Select "rename" button, wait for the conflict dialog on the parent folder
7. Select "replace" button, watch everything unravel

There is a race here between steps 4 and 5, if nemo scans up to the conflicting file the dialog will fully initialize and it is no longer possible to induce the bug. To make the race easier to win one can, make many more files, use files nemo wants to thumbnail, set the detail/list display mode for that folder, umount/mount the media, use slower media like an old SD card, drop vm/fs caches, etc.

Can reliably reproduce this on an old USB flash drive on a USB2 hub with about 15000 small binary files and a 10 year old laptop. Would expect it's harder to reproduce on faster hardware.

Expected behavior

Nemo should not offer to overwrite the parent folder with a conflicted file therein. It should prevent rename operations until the directory scan is done if they cannot be performed safely before that.

Additional information

This might seem pretty corner case and only likely to trip up click happy users. Please note the name of the folder and the mention of SD cards, and the tendency for smart phones users to accumulate many images files in such a folder and such media. This is not theoretical :)

Possibly related to #3597 noting the "" file name in a conflict dialog which is mentioned there.

[jeth-ro]

Attempted fix in PR #3751