GNOME Bugzilla – Bug 87701
files added in background cause re-sort/re-flow and rename to lose focus
Last modified: 2006-11-26 17:07:51 UTC
When renaming a file, if the directory contents change (e.g. you're gzipping a big file in the background), 'fam' notifies Nautilus and the view is updated. The focus to the rename field is lost, however. To duplicate: gzip a large file with -9 (so it takes longer); try several times to rename a file in the same directory; each time it will fail.
Can confirm with 2.2 but only in the list view
*** Bug 110294 has been marked as a duplicate of this bug. ***
*** Bug 111134 has been marked as a duplicate of this bug. ***
*** Bug 111378 has been marked as a duplicate of this bug. ***
*** Bug 126673 has been marked as a duplicate of this bug. ***
*** Bug 127719 has been marked as a duplicate of this bug. ***
*** Bug 128242 has been marked as a duplicate of this bug. ***
I can trigger it even on Nautilus 2.4.1 It seems to happen more frequently using "View as List", but even "View as Icons" isn't immune. It sometimes happens even if the directory contents don't change (but only if FAM is running).
I found it this way: downloading a file with wget and trying to rename a file in that folder with "View As List", it refreshes so quickly so it's impossible to rename it. In "View As Icon" has no problem, the size of the downloading file gets updated while I rename a file. Small Suggest: Maybe implement the "Rename" as a pop-up window in the "View as List" would be an easy workaround (not the best fix)
Today I encountered the same bug while trying to rename a file in a network share with a bunch of mpegs. Nautilus generated a thumbnail in about 2-3 seconds, and every time the rename box would lose focus. This was in the icon view so using a popup for the list view would not help. (BTW the Component field above should probably be changed to View as (Icons or List) -- I cannot do that.) I suppose a simple fix would be to disable view updates while the rename box is active.
This is still happening in 2.6.0. Working in a directory with a file currently being downloaded, rename loses focus every time fam updates the file list (1-2 seconds). Stopping fam ceases this behavior from Nautilus. I'm using 2.6.0, in browser mode, with list view. I updated to 2.6 hoping this would be fixed. Drat.
The same thing happens if you rename multiple files. - rename a file - quickly select another one for rename in the same folder - edit field disappears one or two seconds later because fam notification of previous rename arrives I just deleted a file because of this. I was about to remove a letter from the name (DEL-key) when the edit field disappeared. I'm glad I could restore it from .Trash . This bug should receive increased _priority_ because of possible dataloss.
*** Bug 141524 has been marked as a duplicate of this bug. ***
Still valid for 2.6.x series; upgrading fields.
This is still valid in 2.6.3 open the camera on /mnt drag files to pictures/somedate try to rename pictures/NewFolder to pictures/otherdate.... its impossible... :-/
*** Bug 110295 has been marked as a duplicate of this bug. ***
Changing Summary + Severity -> Major, since this can result in files being permanently deleted just because a new file is added to the directory in the background. Comment from bug 110295 which makes sense, and is what Windows does: "'new' files don't need to go in sorted asap, just append them at the end for the time being - that is, until the user cares and clicks Refresh or Sort".
*** Bug 156567 has been marked as a duplicate of this bug. ***
*** Bug 129795 has been marked as a duplicate of this bug. ***
*** Bug 160996 has been marked as a duplicate of this bug. ***
*** Bug 162207 has been marked as a duplicate of this bug. ***
*** Bug 163042 has been marked as a duplicate of this bug. ***
*** Bug 158366 has been marked as a duplicate of this bug. ***
Removing sisob from the cc list, as unfortunately he isn't with us any more.
*** Bug 166773 has been marked as a duplicate of this bug. ***
*** Bug 146226 has been marked as a duplicate of this bug. ***
*** Bug 159394 has been marked as a duplicate of this bug. ***
Maybe files that are freshly added are appended to the end of the list with a seperater between the sorted list and the new files? This would be like Windows' behaviour but better if there was a clear seperater between them. I'd vouch for this as default behaviour, with auto sorting being available as an option. Another suggestion is if maybe the currently selected file remains in the same position in the view port while other files are added above or below depending on the sorting scheme. This would prevent a jumpy selection. Alex Jones
I don't know... The best solution would be to resort all the items, but the previously selected item should still be selected (or in edit-filename-mode if it was in that mode (F2))
The problem I have with that though is if I've got something selected or I'm ready to drag something and all of a sudden my view is updated with new files, the selection jumps around and I have to go find it again.
Hmmm... You have a point there... In that case, your idea isn't that bad...
*** Bug 168011 has been marked as a duplicate of this bug. ***
My idea isn't that "bad"!? :P Any word from developers as to when this is going to be addressed? Doesn't seem that big of a deal really but this bug is more than two and a half years old! I wish I could code :(
I think the biggest problem with this bug is that by adding items at the end, it is inconsistent with the automatic sorting you have done before... This could be solved by turning the sorting to manual, but when doing so, the user will wonder why the view has turned into manual mode... Still, i think your idea is the best way in solving this...
My 0.05c... I'm quite happy to have incomplete files appear at the end of the listing.. by putting them there the sort sequence of existing files remains unaffected. After all these incomplete files don't really even exist yet. In fact if these files didn't even appear in the main window until they were complete it wouldn't bother me. While a large file is being say downloaded into a directory from the Internet, you don't want to do anything with it, the focus of attention is the other files in the directory we're working on. They need to be accessible. So, have the incoming files at the end of the list with a special icon indicating Locked or Under Creation or whatever.
I'm sorry I have to disagree. I often open long mp3 files as they are downloading. Beep Media Player handles this fine and I can start listening straight away even though the file is incomplete.
How about temporarily disabling auto-update for the window in which the rename is going on, then re-enabling auto-update for that window when the rename operation is over (user has hit enter to "set" the new name or a cancel key to return the name to its previous name)? Other windows showing the same directory could be auto-updating the whole time because the user's attention is focused (no pun intended) on the rename operation.
I agree with J.B. Nicholson-Owens suggestion. Stop refreshing while files are being renamed. I'm going to look into fixing this myself - no promises though! This is the most annoying problem I face on my computer everyday and IMHO should be a showstopper bug. This is major! Hopefully I'll be able to fix it (never looked at Nautilus' code before).
J.B. Nicholson-Owens's suggestions is a very good way to solve the losing focus problem, but what when you were about to drag a file like said in #30? That is still unsolved, and I guess it isn't easy to find a good clean solution for that...
Please, consider my idea in #28! Good, clean solution! A "fresh files" section. Hmmm let me see if I can knock something up in glade or GIMP.
The problem in #30 is a separate bug. Solution: Before refresh, nautilus checks if files were selected and remember them. After refresh, selects them again. The simple and efficient solution for this bug is to stop refresh for current folder when renaming a file, as Owens said. I don't like solution in #28, it looks like an ugly hack which would complicate the code (complicate = maintenance, speed, memory)
If nautilus refreshes while rename is in progress, it should pop up a dialog to support the rename operation - e.g. let nautilus refresh and reflow the icon view, but ensure that the user's immediate rename operation can continue in the foreground. Adding an icon in the dialog that will highlight the just-renamed file would be nice too - this might be a slightly inconsistent approach, but i'd rather have something that works than a half-assed buggy filemanager.
I committed a workaround on HEAD which freezes updates to the list view while the user is renaming. To keep the updates from stacking up infinitely (and eating up all your memory), after a certain amount of changes the view is marked for reload after the rename operation is complete. It's a bit lame but in practice noone will pay attention to changes in a directory while renaming a file anyway (especially since often the changes are not even user-visible). The only workable alternative mentioned here would be poping up a dialog when renaming. But when the list view does that, the icon view should do it too and inline renaming is too sexy to abandon over this. Adding the files at the end or something doesn't help, as every update to the underlying GtkTreeView ends renaming, not just updates to the current file. If no problems pop up with this patch, it should be eventually committed to the stable branch too - as this bug is most annoying. If it's still a problem with the icon view (I never noticed that), it shouldn't be a problem to handle it the same way.
I can confirm that file operations like rename etc. now work OK while files are being loaded into a directory. I tested nautilus cvs Head on a Mandrake 10 box with Gnome 2.11, while cvs was importing files. No problems. Woo-hoo !!
> I committed a workaround on HEAD which freezes updates to the list view while the user is renaming Martin: Does that mean that the src/file-manager/fm-directory-view.c:rename_file hack can vanish?
I noticed besides the renaming issue that right-clicking on a file may not work if the current nautilus view has directory activity such as adding a significant amount of new files. Possibly any sort of right-click event on a file in Nautilus should freeze upate until the popup is dimissed by hitting the close button. my 2 cents.
I committed the patch to the stable branch too, so it'll get into 2.10.2. Christian: No not yet, the change event that takes the focus from the new folder is delivered in the same batch as the creation event. So the freezing needs to stop event dispatching even when already underway. I actually hacked it up, but I feel like I should give it a bit more testing.
No new bug reports on this issue. Martin's fix obviously worked. Closing.
As comment 8 and comment 10 said, there is still part of this bug in icon view, in concrete that icon view looses rename focus when there are file additions/removals in the background. For more details see bug 318373.