GNOME Bugzilla – Bug 96143
Error while ejecting unformatted media from GUI.
Last modified: 2006-12-26 18:31:21 UTC
Steps to reproduce the problem: 1) Insert an unformatted zip/floppy media. 2) Desktop icon for zip/floppy will appear on the nautilus desktop. Right click on the icon and select Eject. 3) One error pops up which states "Nautilus was unable to unmount the selected volume". Details button states 'can't access'. Yet the media is ejected. Error shouldn't appear.
This is happening for all the media which are unmounted(usually all unformatted floppy/zip, read-write protected zip, audio_only CD) When I analysed the code, I found out why there is an error like this. nautilus/libnautilus-private/nautilus-volume-monitor.c:mount_unmount_callback() if (info->command != NULL) { open_error_pipe (); file = popen (info->command, "r"); close_error_pipe (info->should_mount, info->mount_point); pclose (file); g_free (info->command); } if (info->should_eject) { eject_device (info->device_path?info->device_path:info->mount_point); The command for unmounting an unfomatted media is volrmmount -e unformatted_media (Or volrmmount -e password_protected Or volrmmount -e audio_only) Since unformatted media is not mounted, it can not find the file unformatted_media/password_protected/audio_only, and gives out the nautilus error. But it is ejected by the following call eject_device which takes device_path for ejecting.
i dont know if this is at all related, but when i insert a cd and it is automounted using magigdev, i also recieve the sam error when trying to unmount (redhat 8 plus cvs head with fam).
targeting for 2.2, but with lowest priority and severity - the thing works OK, the only problem seems to be the bogus error message.
Created attachment 11841 [details] [review] Proposed patch which avoids error while ejecting an unmounted device
I have found out one more problem while ejecting a media from GUI. Currently nautilus uses "eject <device_path>" to eject the media after unmounting it. But if the device_path has some special characters, the shell may not recognise the path and eject may fail. Code: nautilus/libnautilus-private/nautilus-volume-monitor.c:eject_device() 882 static void 883 eject_device (const char *path) 884 { 885 char *command; 886 887 if (path != NULL) { 888 command = g_strdup_printf ("eject %s", path); 889 eel_gnome_shell_execute (command); 890 g_free (command); 891 } 892 } So it is better to quote(using g_shell_quote() ) the device_path before sending it to eject command. I have created a patch which does this. The new patch also has changes covered in the first patch(patch id: 11841). Please just take the new patch. With the new patch, old patch becomes irrelavant.
Created attachment 11913 [details] [review] Proposed patch with g_shell_quotes
There is a problem with the above patch. The above patch makes Eject happen directly without unmounting and ejecting. But I found that nautilus hangs sometimes in Solaris-9 if I eject the media continuously for 5-6 times. Nautilus does not hang in Solaris-8 if I do the same. (It's because of the difference in the thread implementation between S9 and S8.) I could not fully understand the root cause. But if the eject command is executed with g_spawn_command_line_async(), this is happening. Nautilus is already using a separate thread to mount/unmount/eject a media. And from that thread callback, eject command is executed using g_spawn_command_line_async(), which is asynchronous execution. Note that the mount/unmount command is executed using a synchronous call i.e using popen() from the same thread callback. What is the need for executing a command asynchronously from a thread.?? I have replaced asynchronous Eject command execution with popen() and found that there is no hang. I will attach the patch and pstack of nautilus hang in S9(also pstack of nautilus in S8).
Created attachment 13196 [details] [review] Proposed patch which fixes nautilus hang.
Created attachment 13197 [details] pstack of nautilus hang when Eject is done several times
Created attachment 13198 [details] pstack of nautilus on solaris-8 where hang is not seen
This seems like a rather trivial fix. Is there any reason not to apply it to HEAD? Alex??
As of 2004-01-21, the file that this file references, <file:///cvs/gnome/nautilus/libnautilus-private/nautilus-volume-monitor.c>, does not exist in CVS revision HEAD.
This patch is for fixing removable media related problems in Solaris. It does not apply on HEAD anymore as volume management code has changed in HEAD. Hence closing the bug. Will raise a new bug if the same problem is found to be there on Solaris running HEAD/2.6.
Mass reassigning bugs with 2.2.0 milestone to 2.2.x milestone Grep for "Mass reassigning" to filter out this bug spam.
Mass reassigning from target milestone "2.2.0" to "2.2.x". Grep for "Mass reassigning" to reduce bugspam.