Bug 169404
Summary: | nautilus crashes/closes when deleting a directory | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Harm Verhagen <hverhagen> |
Component: | nautilus | Assignee: | Alexander Larsson <alexl> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-04 15:23:27 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Harm Verhagen
2005-09-27 21:51:58 UTC
From my own experience while moving/deleting my data around, I can confirm the existence of this bug. A gdb trace doesn't capture anything (as user), and as root the gui does not appear and the following is displayed (I'm a first time gdb'er): === gdb nautilus (gdb) run --browser Starting program: /usr/bin/nautilus --browser Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x750000 [Thread debugging using libthread_db enabled] [New Thread -1208858272 (LWP 9943)] [New Thread -1254397024 (LWP 9946)] Detaching after fork from child process 9947. Program received signal SIG33, Real-time event 33. [Switching to Thread -1254397024 (LWP 9946)] 0x00750402 in __kernel_vsyscall () (gdb) === After playing some more I believe this is not a crash; rather it is an unintened effect of nautilus closing its windows when the selected directory disappears. This would not be seen in the fedora's default install since: 1. the nautilus windows do not browse by default 2. you need to additionally set the side pane to tree mode. If however, you either: 1. right click open in browser window, or 2. set edit|preference|behaviour|always open in browser windows then you will see this issue if you use the either: 1. rmdir [folder-currently-selected in tree pane] 2. rm -Rf [folder-currently-selected in tree pane] 3. mv [folder-currently-selected in tree pane] /some/where/else Moving a folder from one to another, you also unexpectedly see this situation. ie you are deep in youy folder structure tidying/moving folders/files around, you do something, and the whole nautilus window just disappears, with no notification. You then think (there is something wrong here), but continue, experiencing the same again. This is quite an annoyance, that should be easily solvable: this is specfic code action (close) taking place when a folder disappears. My solution would be for each open nautilus windows (of any sort) if the displayed / highlighted folder disappears (move/erase) then chase up the through the folder parents path until a folder does exist. eg: /home/me/mystuff/thefolertheatsselected/whatsthetimemisterwolf mv /home/me/mystuff/thefolertheatsselected /home/otheruser the nautilus window would check: /home/me/mystuff/thefolertheatsselected/whatsthetimemisterwolf gone /home/me/mystuff/thefolertheatsselected gone /home/me/mystuff/ exists: place selection and show contents of this folder. This is fixed at least in Rawhide, might be in FC5 too. |