Glitch renaming directory

[Federico Del Bene]

Binary package hint: nautilus

Seen using Ubuntu 6.06 and Nautilus 2.14.1.

Right click on a subdirectory, and copy it in the same directory. You should now have two of them, with second one named "xxx (copy)".
Right click on the latter and choose rename, change the name and before clicking outside or giving a return to save the change, double click on the folder and enter it.
The change will be saved, but the location bar will show the older name.

Another version of this bug shows doing the same without before copying the directory, using directly an existing directory.
In this case nautilus doesn't show the contents of the directory but return this error:

"The folder contents could not be displayed
"xxx" couldn't be found. Perhaps it has recently been deleted."

Of course the renaming has been saved, and exiting and reentering the directory will show correctly the contents.

[Holger Bauer (umarmung-planet)]

I see this too.

[Sebastien Bacher (seb128)]

Upstream bug about that: http://bugzilla.gnome.org/show_bug.cgi?id=337354

[Sebastien Bacher (seb128)]

is that really a bug? you didn't confirm the renaming so the directory has not been renamed yet. what else behaviour would you expect?

[Federico Del Bene (fdelbene80)]

Sebastian, as said in the bug description the change IS saved. It's just the bar that doesn't show the correct name.

[Federico Del Bene (fdelbene80)]

As said in the bug description the change is saved. It's just the bar that doesn't show the correct name.

[Sebastien Bacher (seb128)]

why do you change the status to confirmed? triaged means confirmed and having enough technical details

[Sebastien Bacher (seb128)]

not confirming that the name is already changed, while nautilus is still in edit mode a ls on a command line show the non updated naming

[Federico Del Bene (fdelbene80)]

If you follow the description, you'll see the bug it's still here in Ubuntu 8.04 and Nautilus 2.22.3:

1) Create a directory named A
2) Right click on the directory in Nautilus, select Rename and change the name to B, WITHOUT giving enter or clicking elsewhere
3) Now, with the name still editable, double click the directory to open it
4) The address bar in nautilus will show that the directory is still named A
BUT:
5) If you do a ls command, instead you'll see the directory is now named B
6) If you click the back button in nautilus you'll see the directory as B

This show that at a given time, Nautilus is showing incorrect information and so I call it a bug.

[Sebastien Bacher (seb128)]

not confirming on my intrepid system, running a watch ls in a command line and doing the rename show that the directory name is still not updated while the nautilus icon is in edit mode on my installation

[Sebastien Bacher (seb128)]

do you use the browser mode? in which case that's a race condition and not really a bug, when you double click to open the directory nautilus is still in renaming mode and the directory didn't change, it'll take the action in account, valid the renaming and switch directories

[Federico Del Bene (fdelbene80)]

Look at the attached screenshot.

More than a race condition (where the results can be random) this seems a wrong order of doing two operations: validating the rename and opening the directory. It should first validate the rename and only then show the directory; instead it always first shows the directory, and then validate the directory, leading to the inaccuracy displayed in my screenshot.

[Sebastien Bacher (seb128)]

I didn't say that the race was random, that's just the actions order which is done this way and I don't think that's a bug since that's the directory change that trigger the renaming validation, the bug is rather that when a view is open on a directory which is renamed nautilus should switch to the new directory

[Sebastien Bacher (seb128)]

That's fixed in the current versions with the new rename dialog, you can't enter the directory by clicking it before confirmed the renaming