Bug 885133

Description of problem:
This is a follow-up of bug 819492. It was a Fedora 17 blocker and unfortunately, even though we thought we did, we haven't fixed it properly.

== Brief history ==

In GNOME 3.2 if you tried to eject a flash drive and all data were still not synced to it, there was a pop-up dialog saying "don't eject the drive yet" and then "now you can eject".

Bug 819492 described a regression in GNOME 3.4, the dialog was gone. The code change was intentional, however no code replacement was provided. A proper fix was to be implemented in GNOME 3.6.

The bug was deemed to be critical, because there was a high probability of users losing their data. Also because LiveCDs can't be fixed post-release and are often used for system recovery purposes (thus often interacting with external drives), it was accepted as a blocker for Fedora 17. A simple fix was implemented that makes a gnome-shell-style dialog pop up every time you try to disconnect a drive that is not synced yet.

== Present time ==

In GNOME 3.6 the behavior seems to be completely same as in GNOME 3.4. I don't know if any of the code changed, but visually it seems like the same "quick fix" from GNOME 3.4 remained also in GNOME 3.6.

In bug 819492 comment 72 to 74 we have received some information that this still might be broken. Also I have heard people saying GNOME acts weird sometimes. So I started to investigate and found the issue.

== The problem ==

In bug 819492 the developers have fixed the bug, but just for flash drives. It is not fixed for external HDDs.

If you use a flash drive, it works like this:
* If you click on the unmount icon in Nautilus and all data are synced, the device disappears from the list. It is safe to be ejected.
* If some data are not synced, a gnome-shell popup appears and informs you to wait. After the sync is completely, the device disappears from the list and it is safe to be ejected.

If you use an external HDD drive, it works like this:
* If you click on the unmount icon in Nautilus and all data are synced, the device _doesn't_ disappear from the list, just the unmount icon disappears. It is safe to be ejected.
* If some data are not synced, the unmount icon still disappears and no dialog pops up. There is _no visual difference_ between a safe-to-eject disk and a still-syncing disk (!). And that is what this bug is about.

The question remains why a flash drive behaves differently from an external HDD.

== The difference between a flash drive and an external HDD ==

I think I have managed to find the reason why GNOME acts differently for flash drives and for external HDDs. If you insert a flash drive, a text similar to the following appears in dmesg:

> [33436.521311] sd 6:0:0:0: [sdb] Attached SCSI removable disk

But if you insert an external HDD, the following appears:

> [33436.521311] sd 6:0:0:0: [sdb] Attached SCSI disk

Please notice the missing "removable" word. The difference is the "Removable Media Bit" (google for it). For some reason the flash drives have it and the external HDDs don't.

== Affected systems ==

From my experience anything with GNOME 3.2 or newer is affected. That means Fedora 17 and Fedora 18, I have tested them both.

The most recent builds I have tested with are:
gvfs-1.14.2-1.fc18.x86_64
gnome-shell-3.6.2-2.fc18.x86_64
nautilus-3.6.3-1.fc18.x86_64

With regards to the removable media bit (RMB):
* I have tested 5 different brands of flash drives, all have RMB set (and therefore are safe to use).
* I have tested 3 different brands of external HDDs (Western Digital, Seagate and Transcend), none of them has RMB set (and therefore are unsafe to use). In bug 819492 comment 72 - 74 we also have some further mediated confirmation from other people.
* I have tested an internal SATA drive connected to a PC using a SATA<->USB converter. It doesn't have RMB set (and therefore is unsafe to use).

That makes me think that the numbers are probably very simple - we can say that majority (if not all) of flash drives are safe to use and majority (if not all) of external HDDs are unsafe to use.

== Reproducer ==

1. Open a terminal and a Nautilus
2. Create a 1 GB file
   $ dd if=/dev/zero of=file bs=10M count=100
3. Insert a device you want to test (a flash drive or an external HDD)
4. Look into dmesg and confirm whether it is regarded as removable or not
   $ dmesg | grep "Attached SCSI"  # search for "removable" word
5. In the nautilus copy the file to the device
6. While it is copying, run "sync" in the terminal. You will have it as an indicator that all data are not synced yet (once the command finishes, all data are synced).
   $ sync
7. Immediately once the copy dialog in Nautilus disappears (i.e. the user assumes the copy process is over), but before the "sync" command finishes, click the unmount icon on the device in Nautilus.
8. If a gnome-shell dialog pops up and informs you that you have to wait, congratulations, you're safe. If no dialog appears, congratulation, you have reproduced the bug. Plug the device from the computer. In this case you should see huge amounts of write errors in dmesg afterwards and your file on the device should differ from the file on your computer.

You can also watch my older (very long) video in attachment 582641 [details] where I showcase this with different approaches and filesystems. That was shot in the time where this functionality was broken even for flash drives.

== Proposed solution ==

I have no knowledge of the code in gvfs, so my views can be completely off. But I assume the system should behave the same for both types of media.
* It doesn't matter whether it is a flash drive, external HDD or internal HDD, if I try to unmount/eject it, I should be informed when the data are still being written.
* The unmount icon in Nautilus shouldn't disappear until the sync is done, or it should be replaced with a spinner in the mean time.

== Blocker status ==

Consistently with previous decision in bug 819492, I'm proposing this as a Final blocker for Fedora 18. While this is fixed for flash drives, external HDDs are also used heavily with LiveCDs. Because they are faster, the risk of losing data is a bit lower, but it still seems to be high enough. A loss of user data is always considered as the most critical type of bugs.

I'm very sorry I discovered this so late in the cycle. But I believe we would strive for a very fast fix in all cases, because it also affects users of our stable release (Fedora 17).