GNOME Bugzilla – Bug 310205
pathbar inconsistent when clicking a folder that no longer exists
Last modified: 2010-09-08 10:44:57 UTC
- Open a browser window - Create a folder - Open the folder - Go back to the parent folder - Remove the newly created folder - Click the old folder that is still in the pathbar A message is shown: Can't display location Please check the spelling and try again. The removed folder-button is still in the down state. I guess perhaps the pathbar can communicate with FAM or so and remove the button if the folder is removed also...
Created attachment 49081 [details] screenshots say more then 1000 words
Thanks for your bug report!
*** Bug 310920 has been marked as a duplicate of this bug. ***
*** Bug 320129 has been marked as a duplicate of this bug. ***
I've askes Alex about the problems and here is what he thinks: Is this really a huge problem though? If you click on on the deleted folder, don't you get told that its not there anymore? The problem with monitors are: a) They can keep a mount from going unmounted. This is fine if you're actively displaying the mount, but is very weird if something passive like the "history" in the pathbar actively blocks an unmount b) They are not especially cheap. Especially the way we now handle monitoring in Nautilus, always watching the whole directory.
"Couldn't find "/home/alex/untitled folder". Please check the spelling and try again." a) This is a BAD error message. Spelling has nothing to do with it. Whatever needs to be done to change this needs to be done. b) Clicking OK leaves the button in a pressed state. This just seems wrong. The button should not be insensitive, because the folder might re-appear, but I suggest an X icon on the button to indicate that it was inaccessible or something. Also if you are already monitoring the current folder for changes, we might as well detect folder deletions (if not the entire tree). And monitoring blocking unmounts? That just seems fundamentally wrong. If you are monitoring a folder and then it is unmounted, that should surely trigger something, much the same way as deleting the folder would.
I may be totally wrong since I didn't look at the code, but does this really need to be done using monitors? I guess that removing the deleted subdirs from the pathbar after activating the delete command from nautilus would catch 99% of the cases. If someone rm -rf from the shell he'll continue to get the current error dialogs.
I agree with you Paolo.
*** Bug 317851 has been marked as a duplicate of this bug. ***
*** Bug 333325 has been marked as a duplicate of this bug. ***
*** Bug 334348 has been marked as a duplicate of this bug. ***
*** Bug 352985 has been marked as a duplicate of this bug. ***
Still occurs with Nautilus 2.17.92 on Ubuntu Feisty.
(In reply to comment #7) > I guess that removing the deleted subdirs from the pathbar after activating > the delete command from nautilus would catch 99% of the cases. Bug 327691 has a patch that does this.
I would expect that when a folder is renamed, nautilus would perform the operation and update the location bar and the folder contents of all affected open windows to reflect the change. The same goes for removing a folder. If I'm not mistaken, the folder contents of all affected open windows are updated this way. Why not the location bar as well? If a folder is removed, the buttons in the location bar for that folder and any subfolders should be removed.
*** Bug 481442 has been marked as a duplicate of this bug. ***
does this still happen with 2.21.x?
Hello Andre, Yep it's still accurate
then crevette may want to update the version info :)
*** Bug 529250 has been marked as a duplicate of this bug. ***
Bug 549086 has a screenshot as well...
*** Bug 549086 has been marked as a duplicate of this bug. ***
*** Bug 549109 has been marked as a duplicate of this bug. ***
*** Bug 327691 has been marked as a duplicate of this bug. ***
Duplicate bug 327691 has an unfinished (and probably obsolete) patch that could be used as a starting point for this (attachment 78415 [details] [review]).
Created attachment 137519 [details] [review] Patch to remove non-existant path buttons Patch against nautilus 2.26.2. (May not completely unref memory...) This removes the button corresponding to a deleted directory (and the ones underneath). This also fixes handling of buttons on folder renaming.
*** Bug 587393 has been marked as a duplicate of this bug. ***
The patch seems to be mixed with some other different stuff which doesn't belong to this bug fix. Anyway, I am cooking up an updated patch for this that takes care of also removing the trashed items from the Nautilus history as well.
2.27.5 still has this problem.
Created attachment 142368 [details] [review] Patch to remove non-existant path buttons (revised) Here's an updated patch (against HEAD) with the extraneous code removed (sorry!). I also started looking at fixing the history list, but am making slow progress...
Created attachment 142369 [details] [review] update history when folder is renamed I did find the history code that handles renaming folders. This patch seems to work, but I'm still working my way through the many uses of NautilusBookmark.
*** Bug 619759 has been marked as a duplicate of this bug. ***
We should definitely take care of this for 3.0.
(In reply to comment #33) > We should definitely take care of this for 3.0. Is the patch in comment#31 good? Maybe we can milestone it so that we dont miss it?
Comment on attachment 142369 [details] [review] update history when folder is renamed This was just a workaround. I fixed the root cause in master, see http://git.gnome.org/browse/nautilus/commit/?id=d1446086855ec1a673b144befff5b707244b998c
I committed that patch minus some bit of changes to master, so that we can at least fix this bug for the pathbar.
*** Bug 620964 has been marked as a duplicate of this bug. ***
*** Bug 627007 has been marked as a duplicate of this bug. ***
*** Bug 629030 has been marked as a duplicate of this bug. ***