Comment 30 for bug 466575

Having the same issue with two USB disks: SAMSUNG_SV2042H and Myson_Century__Inc._USB_Mass_Storage_Device_100.

I did some debugging and this is what I came up with:
When you right-click on a USB drive and choose "Safely remove drive", this is what happens in the background:
1. Nautilus calls udisks --umount <device file of USB drive>"
2. udisks contact a background-process named "udisks-daemon".
3. udisks-daemon inturn invokes "/usr/lib/udisks/udisks-helper-drive-detach".
4. udisks-helper-drive-detach calls some sg3-utils to synchronize the cache and stop the device ("sg_ll_sync_cache_10" at line ~184 and "sg_ll_start_stop_unit" at line ~202 in source file "job-drive-detach.c"). Both of these functions return an error message.

You can easily reproduce the error messages caused by sg3-utils by running the sg3-utils manually. In order to reproduce the first error message ("SYNCHRONIZE CACHE: FAILED: No such file or directory"), run this command:

sg_sync --verbose <device file of USB drive>
Example: sg_sync --verbose /dev/sdc

This yields the precise error message returned by the sg3 backend:

    synchronize cache(10) cdb: 35 00 00 00 00 00 00 00 00 00
synchronize cache(10): Fixed format, current; Sense key: Illegal Request
 Additional sense: Invalid field in cdb
bad field in Synchronize cache command

In order to reproduce the second error message ("STOP UNIT: FAILED: No such file or directory"), run this command:

sg_start --stop --verbose <device file of USB drive>
Example: sg_start --stop --verbose /dev/sdc

Again, this yields a more precise error message than the general "No such file or directory" as shown by the graphical front-end:

    Start stop unit command: 1b 00 00 00 00 00
start stop unit: Fixed format, current; Sense key: Illegal Request
 Additional sense: Invalid field in cdb
invalid field in cdb
START STOP UNIT command failed

In conclusion, it looks like the sg3-utils send the wrong commands to the SCSI layer or wherever these commands go (I am not that much into low level SCSI programming, my apologies). However, I don't see any adverse effects from these erroneous commands. Even though the sg3-utils functions return an error, udisk-daemon properly continues and cleanly unmounts the USB drive as far as I can tell (it invokes umount, which should sync the cache anyway). To try this out, I removed the two calls to the functions "sg_ll_sync_cache_10" and "sg_ll_start_stop_unit" from the source code of udisks "job-drive-detach.c" and recompiled the thing. Nautilus stopped whining about the failure of these two functions and the drives are unmounted perfectly. :-)

I would have attached a patch, but I do not really have a clue about what these two functions do precisely. In fact, it might have been a bad thing to remove the function calls from "job-drive-detach.c". I cannot say, if this may result in loss of data (someone with some SCSI programming knowledge please explain). Plus, I imagine that for most users it may actually be useful that these functions are called. So it would not really be a patch.