Hello,

First of all, I'm not sure if it is the correct subforum to post this, or even the correct forum.

I stumbled on a problem the other day. I understand that it is a general linux problem (or isn't it?), but one that the desktop could be completely hiding from the user.

So, what did I do:
1. I plugged an USB key in my laptopn
2. The key appeared in the "Devices" icon
3. I clicked to mount it or open it in dolphin
4. I was unable to copy files onto the key, with some cryptic message in the status bar of dolphin

After investigating, apparently the key was "damaged" (it had not been properly expelled at some point), and the behavior in this case is to mount the key as read-only.
The fix is described in many places, such as here (2-years-old page). Note how the fix consists of 3 commands and does not really require any human interaction.

Now, I'm not afraid of the command line, it took me 15 minutes and all was well. But linux is supposed to be for everybody today, how would your grandma react to this problem? Probably throw away the USB key and purchase another one, no?

Precisely, I see two serious UI flaws here:
1. The problem is not obvious At step 2, there could be a notification saying that the key is potentially damaged. At step 3, there could be a popup or a notification stating that the key is potentially damaged and was mounted read-only. At step 4, same thing.

Either solution would be fine, but none is applied. At step 4, if you don't look on the status bar, it's not even clear why drag-and-drop doesn't produce the same behavior as usual.

2. There is no fix offered As said above, the fix is only 3 commands. What is wrong with, when mounting, having a popup window explaining the problem (in simple words), and offering to auto-repair or mount as read-only (call that "safe-mode" for your grandma)?

Instead, we require the user to go through the process of plugging and using his key as far as he can before he actually tries to write something.
At this point, he notices that it doesn't work, and maybe also a message on the status bar stating that it doesn't work (duh).
Then he needs to open google and figure out some keywords explaining his problem (it turns out that "unable to write files on my USB key linux" does show relevant results, but also a lot of irrelevant pages; for the more tech-literate "linux read-only usb" works fine, but that's not what the average user will type).
Then (hopefully), he finds the answer, which will usually be to either:
- go through the above-mentioned 3 commands (in a terminal ! would you really ask your grandma to type commands in a terminal?)
- plug the key in a windows computer and let windows auto-repair it (!!!)
- go through various other processes which may or may not work

I don't think any of this is making the linux KDE desktop stand favorably against windows. As I said at the beginning of the post, I believe that deep down the problem is in linux's hand, or whoever is in charge of mounting the USB. But at least UI-wise, there must be something that can be done, no?

> As said above, the fix is only 3 commands
No, it's actually not.
All that's known (though I doubt to KDE or dolphin) is that the FAT is inconsistent. Whether that is because of a layer 8 error or because the key is actually broken is unknown.
In the latter case, you do absolutely not want to rw mount the key.

> What is wrong with, when mounting, having a popup window explaining the problem
=> udisks behavior, udisks problem, udisks solution required.

I doubt that the reason for the ro mount is wired up by even udisks, let alone self-contained "we know bettter" udisks2

What probably should happen is that "something™" fires a signal or just spams a dialog/message when the EBKAC unplugs the mounted, unsynced and accessed usb key, asking him to replug that thing at once, wait for the UUID to show up again and then triggers a repair.

"Something™" *could* be dolphin (bad idea, probably not even running anymore when the key is unplugged), some KDE daemon or some system daemon (preferably udisks...)

Acting when the inconsistent FS is to be remounted is too late and would indeed require knowlege, privat to the user ("d'ohhh - me fool, should not have unplugged it early", resp. "errrr wait what??? uuhhh-ohhh!")

luebking wrote:> As said above, the fix is only 3 commands
No, it's actually not.
All that's known (though I doubt to KDE or dolphin) is that the FAT is inconsistent. Whether that is because of a layer 8 error or because the key is actually broken is unknown.
In the latter case, you do absolutely not want to rw mount the key.

In the latter case, would attempting to fix actually cause any damage?

About what is known, KDE and dolphin should certainly know that the key was mounted read-only. Maybe there is a way, UI-wise, to issue a warning which could be disregarded by techies who did willingly mount their key ro, but give clues about the problems ahead to the rest of the users?

> What is wrong with, when mounting, having a popup window explaining the problem
=> udisks behavior, udisks problem, udisks solution required.

I doubt that the reason for the ro mount is wired up by even udisks, let alone self-contained "we know bettter" udisks2

What probably should happen is that "something™" fires a signal or just spams a dialog/message when the EBKAC unplugs the mounted, unsynced and accessed usb key, asking him to replug that thing at once, wait for the UUID to show up again and then triggers a repair.

That would be a partial solution to the problem, but only partial. In my case, the faulty USB had been unplugged while mounted on a windows machine, so there's nothing KDE could have done to prevent the problem from appearing.

Acting when the inconsistent FS is to be remounted is too late and would indeed require knowlege, privat to the user ("d'ohhh - me fool, should not have unplugged it early", resp. "errrr wait what??? uuhhh-ohhh!")

It is about repairing a mistake: sure it's too late (it would have been better if there had been no mistake at all), but better late than never, no? Or are you saying that copying the files over and then throwing the key away is actually the way to go for the random user in this situation?

Windows does it with a simple "Something's wrong with this key. Should we fix it, or should we ignore?" dialog. From what I understand, its only criterion is whether the dirty bit is set, so "ignore" is a safe option in most cases, and I have never heard of a case where fixing did cause more harm than doing nothing. It doesn't require any knowledge, and it doesn't even explicitely states that the problem comes from the user in the first place.

What's wrong with this approach? Or is it that udisks2 will not issue any warning when mounting the key read-only? (I didn't think of checking my logs the other day)

Any write attempt to an actually faulty device can have random consequences, potentially destroying (more) data.
What you really do want in such case is to dump the data as good as possible (dd_rescue) and throw away the key, yes.

"KDE" (or "Dolphin") knows the mount options via KMountPoint, yes. However not the (ultimate) reason.

> It is about repairing a mistake
No. It. Is. Not.

It was in *your* particular case, but at this point it's completely unknown whether the reason is a mistake or a broken device.
The attempt to "fix" a broken device can result in additional data loss, so what could be done is to inform the user that either he made a mistake or data loss may be imminent.

The offer then needs to be to secure the flash data and/or unmount the stick, perform an fs check and remount it, so that the user can take an informed decision, based also on his personal memory on what he did to the key. In addition, one could perform sanity tests on the key (multiple writes and reads of controlled data) and play back the secured data.

If udisks doesn't wire up the reason for the ro mount, this will of course cause some nasty false positive warnings (eg. if the key is automounted ro by some rule or hardware protection because it contains private data, like a signature, which is supposed to be not manipulated; is used to cross an air gap; etc.)

> "Something's wrong with this key. Should we fix it, or should we ignore?"
That is likely because windows can assume that the vast majority of its users are complete idiots :-P

Seriously, that approach is not helpful. Assisting the user is fine, but automagically destroying his data is just lame.
There's no simple "grandma compatible" solution at this stage (unlike yelling "you should not have done that" when the user unplugs a key in access - at this point it's perfectly known that something wrong happened *and* it can even be fixed completely by replaying the unfinished action)

Otherwise udisks could instead of performing a ro mount, perform a dosfsck and then a regular mount.

> Or is it that udisks2 will not issue any warning when mounting the key read-only?
I don't think it will, but that's irrelevant.
The ro state is detectable nevertheless but the condition of the key no more reliably - neither by udisks nor anything else.
Manual intervention and a user choice seems inavoidable to me (unless you want to force a dump/fs check/2nd dump/sanity check/replay process on the user in every occasion)

luebking wrote:Any write attempt to an actually faulty device can have random consequences, potentially destroying (more) data.
What you really do want in such case is to dump the data as good as possible (dd_rescue) and throw away the key, yes.

"KDE" (or "Dolphin") knows the mount options via KMountPoint, yes. However not the (ultimate) reason.

> It is about repairing a mistake
No. It. Is. Not.

It was in *your* particular case, but at this point it's completely unknown whether the reason is a mistake or a broken device.
The attempt to "fix" a broken device can result in additional data loss, so what could be done is to inform the user that either he made a mistake or data loss may be imminent.

Okay, that makes sense.

> "Something's wrong with this key. Should we fix it, or should we ignore?"
That is likely because windows can assume that the vast majority of its users are complete idiots :-P

It's probably backed with statistics.

More seriously, since afaik unplugging an idle key without unmounting it triggers the "repair" dialog, statistically, a lot more "repairs" are safe.

> Or is it that udisks2 will not issue any warning when mounting the key read-only?
I don't think it will, but that's irrelevant.
The ro state is detectable nevertheless but the condition of the key no more reliably - neither by udisks nor anything else.

But the key could be mounted read-only legitimately. I'd expect that udisk knows the difference between "fstab asked for ro", "the key could not be mounted rw" (physical switch) and "I could have mounted the key rw but decided not to". But now I understand why desktops (not only KDE) decided not to second-guess udisks on that.

Manual intervention and a user choice seems inavoidable to me (unless you want to force a dump/fs check/2nd dump/sanity check/replay process on the user in every occasion)[/quote]

But as you say (re-quoting this):

what could be done is to inform the user that either he made a mistake or data loss may be imminent

Yes, please.