GNOME Bugzilla – Bug 89616
renaming in sub-folders broken
Last modified: 2009-08-15 18:40:50 UTC
Steps to reproduce - Open up applications:/// File->New Folder [to get Untitled Folder] Try to rename it [not that it matters] - fails in nautilus Refresh view, 'Untitled Folder' disappears. Nothing is created in $prefix/share/gnome/vfolders or equivalently in ~/.gnome Similar behaviour for applications-all-users:///, preferences:/// and preferences-all-users:///
Okay, this still doesn't work in the latest sources... For preferences:/// and applications:/// it creates a vfolder-info file in ~/.gnome/vfolders with <Exclude>untitled folder</Exclude> Tried to test it for applications-all-users:/// and nautilus just hung :( Not entirely sure how I attach gdb and get the 'real' reason for this hang :/
*** Bug 90884 has been marked as a duplicate of this bug. ***
Renaming new folders or those without .directory files should work with latest CVS. Leaving open until we support changing the lacale's Name attribute in the .directory file for the folder being renamed.
Created a new folder/submenu [called 'Submenu'] in a nautilus applications:/// view. Seemed to work nicely...refreshed...then changed the icon for this menu item - and somewhere along the way it lost all the Name and remembered it as 'Menu'. The same happened for applications-all-users:///
Okay, so this should be "working" in current CVS... it now correctly sets the locale-specific Name in the folder's .directory file, if one exists. However, it appears that nautilus does not monitor .directory files in subfolders of the current folder, so the name change will not be displayed until you refresh in nautilus (though it should show up in the panel immediately). But again, this only occurs when renaming folders which contain .directory files. Adding Dave to CC to get some feedback...
Updating the title a bit- I'm not sure I completely understand, though.
So this is actually a nautilus bug. For some reason nautilus is not invalidating the file->display_name on directory renames, only file->cached_display_name. The following patch fixes the problem, but causes the name displayed to fallback to the relative URI. What should really happen is to show the relative URI after a rename, but also kick off the reading of link_info. Once the display_name is read from the .directory file, the view should be updated. Also, this uncovers the fact that nautilus does not watch .directory files for changes.
Created attachment 10657 [details] [review] makes renames work, but is probably wrong
I'm still seeing problems with renaming folders in applications:/// when I create a new folder I don't even get the option to give it a name - it is just created as "untitled folder". then when I try to rename it, it flashes into 'name mode' (i.e. to allow user to change name) for a second and then reverts back to "untitled folder" this is only happening in applications:/// - I have no problems renaming new or existing folders in applications-new-users:/// or any other folders for that matter. just shout if you need me to get more info
adding cc
I just checked a fix for this into gnome-2-0 and HEAD. Lemme know if you need a sun_patch.
The fix as commited on HEAD seems to make directory switching a whole lot slower.
I.E. backing out the nautilus-file change makes loading a four file directory instant, while with the change it takes about a second (triggering the 1-s pause reflow).
I have verified this as fixed in sun's beta2 build9 (cvs 17th sept) - found new problem where changes to existing folders (Accessories, etc) are not reflected in Nautilus - opening new bug for this (bug #94084)
*** Bug 91155 has been marked as a duplicate of this bug. ***