Comment 3 for bug 235878

Revision history for this message
Michael Roy (mikemlp) wrote :

That is unfortunate. Now that I am aware of this behavior, it is easy enough to work around, I just wish that I hadn't learned by losing data. The only thing I can suggest is to try again with upstream. Perhaps "bump" the message on the 16th, 1 week from original posting. It may have gotten lost among pre-existing discussions of ongoing debate on the list.

On the mailing list, you said, "I've noticed this bug has been reported in the past, and that on the bug-page it was mentioned that if this bug were to show up again to e-mail the list." Do you have a link to the past bug report in Gnome's bugzilla? Linking to the bugzilla report that you saw might also be helpful to anyone considering a response on the mailing list, if you choose to "bump."

Out of curiosity, I notice that this bug is marked "incomplete." I am unsure of the criteria for each of the various "status" options, so I'm imagining, without having all of the information, what is required to change a bug's status from "incomplete" to "confirmed." Does it require several users to notice the same behavior? If so, then another user has reported identical behavior in the forum post that I have linked to in the original report. Does it require that upstream acknowledge the bug? If so, then it seems we are back to waiting for the nautilus mailing list.

I think this scenario is pretty easy to duplicate, but please let me know if any additional information is required, and I will be happy to assist.

Finally, one additional note: If one follows the youtube video exactly, deleting /fat/oh-no, and causing /fat/Oh-no to be deleted, if one then decides to create a new folder, /fat/Oh-no following the deletion, this creation of /fat/Oh-no will also "respawn" /fat/oh-no automatically. The only way that I could find to end this behavior was to log out of gnome, return to GDM and log back in. In summary, it appears as though nautilus "remembers" the duplicate state of a previously deleted folder affected by this issue while in the same gnome session. As you might imagine, this made it take longer to get a "clean" video of this behavior in action. I share this anecdote in hopes that it might help track down the source of the issue.

Thank you both for your efforts, I will check back periodically.