GNOME Bugzilla – Bug 646900
Can't rename in icon view, when scrollbars are visible
Last modified: 2011-10-20 15:55:44 UTC
nautilus-3.0.0-1.fc15.x86_64 I can't rename files at all. I select a file (that I have just created so permissions are not the issue), right click on it, select rename, and nothing happens! Strangely, it doesn't work only on icon view. In other view modes, rename works just fine.
(In reply to comment #0) > Strangely, it doesn't work only on icon view. In other view modes, rename works > just fine. I am using your very same package, and I can't reproduce this. Can you try starting nautilus from the terminal and see if it produces any interesting output while the rename fails? Does this bug happen only in some directories for you or everywhere?
That's really strange. Renaming doesn't work in my home folder, and in my Downloads folder, but it does work in many other folders including newly created folders... Terminal output: Gtk-Message: Failed to load module "pk-gtk-module" Initializing nautilus-open-terminal extension Initializing nautilus-gdu extension Initializing nautilus-sound-converter extension Initializing nautilus-search-tool extension
*** Bug 646917 has been marked as a duplicate of this bug. ***
There is also a problem for me: Not possible to Rename any file or dir on External Drive (home folder is ok), no errors.
*** Bug 647869 has been marked as a duplicate of this bug. ***
Oh ... Now I see the problem more than I extended the previous response: can rename in the main home folder but can't rename in all sub-folders of home folder. By the way, for me, the problem started just now in version 3.0 and not in version 2.91.x (with the switch into the gnome 3). Terminal output: but is the "normal" warning - for this problem, no any errors. (nautilus:24231): Eel-WARNING **: "unique eel_ref_str" hash table still has 4 elements at quit time (keys above) (nautilus:24231): Eel-WARNING **: "nautilus-directory.c: directories" hash table still has 1 element at quit time (keys above) --Gnome 3 on archlinux, package - testing/nautilus 3.0.0-1 x86_64.--
Seeing this too. Nautilus 3.0.1-1 on x86_64. Can't rename a folder (only) when it is in another folder. Weird.
I can confirm this. Nautilus 3.0.1-1 on x86_64. Once the scroll bar appears, i cant rename any folder, only happens in icon view.
Continues in Ver. extra/nautilus 3.0.1-2.
I just got an update to nautilus-3.0.1.1-1-x86_64 seems to work now. Can anyone confirm this?
nautilus-3.0.1.1-1.fc15.x86_64, bug still there. Only when there is a scrollbar though, when the window is maximized, I can rename.
Ah yeah, I can only rename when its minimized. Maximized and scrollbar doenst work.
I tracked this down (at least on my system). The file ~/dconf/user seems responsible for this behaviour. After renaming it renaming works as expected. There are other user made settings saved in this file. Unfortunately I deleted my "malfunctioning" file. Perhaps one of you guys can upload it for investigation. As dconf uses a binary format (it's a pity imho) I unfortunately can't provide more debugging help. Greetings, Flo
on my system, i have the file in this path ~/.config/dconf/user, But if i change filename it's remake this file, and not fix the bug...
Yeah, i typed the wrong path ~/.config/dconf/user I removed the file while not being logged in in GNOME. Additionally, try to add a new user and try whether this bug persists. My approach was to rename my .config folder (or its subfolders in later stages) so GNOME didn't find it and step by step I got closer to the root of the problem. Try this too please, to provide more Information. Greetings, Flo
Ok, After rename the user filename and log in to GNOME, I get the GNOME clearly but rename not work. Check as my user and as root. Currently, I cannot run X on new user, problem in the system... sorry.
*** Bug 649576 has been marked as a duplicate of this bug. ***
Nautilus 3.0.1.1 on x64. After starting Nautilus Rename (F2) doesn't work in List view (default). Changing to Icon view Rename works and changing back to List view Rename still works. When my Home folder's view is changed to Icon view, after Nautilus restart Rename works. It seems to me this error occurs when a folder's default view is List.
I can reproduce the problem too: When I'm in this directory (in nautilus): ------------------------------------------------------------------- [hedayat@localhost ~/بارگیریها]% pwd /home/hedayat/بارگیریها [hedayat@localhost ~/بارگیریها]% ls 10.1.1.42.195.pdf rms-essays.pdf 13-refppt.ppt RoboCup2011_OfficialPoster.pdf 346_610.PDF saaghar-data_58.90.02.deb cloob_security.png se5.pdf DevIL-1.7.8.tar.gz sexpr_1.2.1.tar.gz DSC00001.JPG SphinxTest.zip eclipse-fullscreen_1.0.7.zip t facebook-hedayatvk.zip tbb30_20110315oss_src.tgz FoxitReader-1.1.0.tar.bz2 themeselector-0.9.tar.gz glog-0.3.1.tar.gz tp-space_iros06.pdf google-talkplugin_current_x86_64.rpm Triclops3.2.0.8-FC1.tgz guimoo-0.2.tar.gz virastyar-v1.1.41-full.zip linux-live-6.3.0.tar.gz virastyar-v1.1.41.zip mingw32-intel-tbb.tar.gz Wallpapers-WhiteFlowersPack.rar MOV01508.MP4 zb_20_game.tar.bz2 --------------------------------------------------------------------- In the default icon mode, I can't rename any files or directories. It does depend on the directory path AND its contents. If I switch to the list mode, I can rename. When I reverted back to the icon mode, I cannot rename again. However, notice that it depends on the current locale. If I select English locale, I can rename in the same directory with the same contents, but if I log out and login in a new locale (I use fa_IR.UTF-8 locale), I cannot rename files/directories again. So, it depends on the selected locale too.
I'm running fedora 15 Beta x86_64, with all updates applied up to 2011-05-16. In Nautilus 3.0.1.1.-1.fc15: I have a folder on an SD card, with 450 .txt files in it. The files are owned by my user and group, and permissions are -rw-r--r--. In the Compact view, I can only rename files in the first column. The second and subsequent column display no response to <F2>, Edit->Rename or right-click->Rename... If Nautilus is showing 10 rows of files, I can rename the first 10. The eleventh (or first in second column) won't rename. If I make the Nautilus window bigger, say, to 12 rows of files, I can rename the first 12. From the first file in the second column onwards, Rename won't work. In Icons view or List view the Rename function works correctly on all files in the folder. I'm using English, but some of the file names contain foreign accents (Portuguese language). If the folder contains only English language filenames, I can rename files in other columns.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I can confirm this bug. Name : nautilus Version : 3.0.1.1-3 Running Arch Linux x86_64. Can't rename using 'F2' or by right clicking on a folder and then clicking on 'Rename'.
Just upgraded to 3.0.2-1. The bug is still present. Why is this still UNCONFIRMED?
The following is the information I entered for bugzilla.redhat.com bug # 707546. This looks like the same problem. Description of problem: I took a few screen shots. Then I wanted to move them into a new folder. I opened nautilus and navigated to Pictures. I then right click to create a new folder. Great, now I have a folder named "Untitled Folder". So I right click on that folder, and select "rename". The folder is highlighted, but when I type anything the folder name is not changed. Instead nautilus appears to use my key strokes for navigation. No matter what I try, I am unable to change the name of the folder from within nautilus. To me this problem is so severe, it is a complete show stopper for using GNOME 3 under Fedora 15. Granted, I can drop to a terminal window and rename the folder, but most of the people I would want to recommend to use this are not comfortable doing anything in a terminal without explicit directions every time. Version-Release number of selected component (if applicable): nautilus-3.0.1.1-1.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 1. Open nautilus to a folder with lots of files. 2. Create a new folder. 3. Try and rename that folder. Actual results: Rename is focused on the icon, with the keyboard still controlling navigation. Expected results: Rename should place the focus on the filename, and it can be changed. Additional info: --- Additional comment from briemers@redhat.com on 2011-05-25 07:47:23 EDT --- Note: This bug seems related to 702142. Only in that bug, somehow the user managed to actually rename the file despite the navigation focus. I cannot even get nautilus to do that, so there must have been a further regression since that bug was filed!
I tried other folders, but I did not see the same problem. I copied my Pictures folder with a cp -a command to Pictures2 and that presented the same problem. If I deleted any file in the folder, then the problem no longer occurred. I resized the window, and now to only does in not occur in copies of the folder, but it does not occur in the original either. I notice one time when I went to rename, the edit box did appear, but it appeared below the bottom of the window... Other times I did not see the edit box at all. More experimenting demonstrates the problem comes and goes with resizing the window. is it looks like it is dependant on the rendering of the icons/images v.s. screen size. If the text turns grey when I right click I will be able to rename. If it remains solid blue I will not be able to. Strange. I guess until the problem is found, the workaround is to resize the window until it works right.
One particular thing about the pictures folder that is different from most other folders, is the aspect ratios vary based on picture aspect ratio, and many of the files have long filenames that take multiple lines to view in icon mode. I'm sure both these factors are raising havoc with the algorithms that decide how to lay things out and where to display the text edit box. Especially since typically the edit box is a slightly different size that already reserved for displaying the filename, so probably the first thing that happens when I go to rename a file is the position of every icon is updated to make room...
I can't reproduce this bug in icon view. Anyway, I just submitted a fix for the renaming bug in list view that some comments here also mention. It's bug 656128.
as a workaround, left click on a file before trying to rename.
bug 659036 might be a duplicate.
*** Bug 659036 has been marked as a duplicate of this bug. ***
Rui, Cosimo: I've found the source of the bug: it's a resizing problem. When you try to rename a file, the layout changes, and for a split second gets one additional column. This is visible in my tests: the bug only occurs under very precise window height conditions, only when the files are shown on 3 columns, and expanding the window a little more would show 4 columns. In that case, when I rename files that are on the first two shown rows of the view (not the two first of the folder), the 4-columns view is visible for a split second, and disappears immediately - it's only visible if you look at the blank space when it occurs. Other observations: - renaming files from the first row always works - if you try to rename a file from the last row, the scrollbar and the view jump by about to rows up (it doesn't happen for other rows) So I suspect that when renaming, the files' width reduces a little, enough to fit an additional column in the view. This makes everything move, and for some reason editing is canceled. This is why the bug only happens very rarely: you need to have a window size that almost shows 4 columns, but lacks one pixel. Bug 659036 has two screencasts that show the problem. I'd like to underline this is a major bug. For people experiencing it, file renaming is broken, and it took me months until I understood that resizing the window is a good workaround.
By the way, I cannot be able to reproduce it with Nautilus 3.1.92. So it is a bug in 3.0.x version only.
Are you sure? It's quite hard to reproduce when you don't know the conditions. A simple window resize is enough to make it vanish.
Actually it is very trivial to reproduce. The exact number of columns does not matter (unlike what is reported in comment 31). The important thing is the window is sized close to where it will need to re-space the icons. I find the problem is much easier to produce in a folder with long file names that wrap several lines and lots of photos with different aspect ratios. e.g. I see the problem almost 100% the time in my Pictures folder. I typically have to resize the window two or three times before I happen to get a layout where rename works. Of course the easier workaround is just to switch to list view. I don't have Nautilus 3.1.92. Is there an easy way to install that on Fedora 15, so I can see if the newer version has the same bug?
*** Bug 653884 has been marked as a duplicate of this bug. ***
It is apparently fixed in nautilus 3.2.
Works in 3.2, closing.