Quote:
Originally Posted by ixtab
Then, the system actually reports the file system as mounted, but it's simply empty. As soon as the user unplugs/ejects the drive from the computer, files appear. I don't know how exactly they solved this, but it makes perfect sense: it is a very bad idea to access the same filesystem concurrently (especially with FAT, which is pretty fragile anyway).
|
Yes and No.
Under Linux you can mount a device holding a file system multiple times.
No harm in that, the file system operations are 'atomic' at the user level (they block the requesting process until they complete).
There are exceptions to that general rule, but VFAT isn't one of them.
With a device holding a file system mounted multiple times, if the file system isn't designed to deal with "function clashes" (such as name clashes, two processes, one deleting a name, one creating the same name - etc), and VFAT isn't, then as a programmer, you just have to avoid that situation.
Just avoid modifications to a file name that might be expected to be unchanging when the <whatever> views the file system from the other mount point.
But even if such a "function clash" happens, only one of them will win the race, the file system will survive (and record only the winner).
One other thing to keep in mind -
The possibility of a mis-leading message. Where you are getting a "mounted" indication might only be a "device busy".
umount -l (ell) can help in such a situation.
But the "other" application might error out when it tries to unmount (expecting that the filesystem only needs to be unmounted once, rather than twice or twenty times).
At which point I would have to agree - something is probably going to "hang" or "crash" if it is written to expect a file system to stop being busy with a single unmount command.
lsof might also be of help in this situation.
I admit, I don't know what information it will return for a file system OTG exported - but it should have something useful to say. (along with ps aux)