On May 23, 2012, at 6:11 PM, Alan Stern wrote: > On Thu, 24 May 2012, Pantelis Antoniou wrote: > >> OS-X uses a sequence on unmounting that makes us close the backing >> file. > > What do you mean? Does OS-X send an eject command (as far as I know, > that's the only command that will cause the backing file to be closed)? > OS-X does sent an eject command. >> Apparently there's no way to open it again, which makes it >> impossible to remount without rmmod'ing g_mass_storage. > > That's not true at all. If the backing file has been closed, it can be > re-opened (or another file can be opened in its place) by writing the > filename to the gadget's "file" attribute in sysfs. > Arguably that's not what you want, nor you expect. Linux doesn't sent the eject command so when you reconnect the cable the original configuration (i.e. the old mass storage file) is used. Without this you need to either rmmod, or rewrite the filename to the gadget's "file" attribute whenever the host umounts sending an eject command. So what we have is this: Linux host unmounts, backing file is not closed, disk will appear when another mount command is issued, without having to write the "file" attribute in sysfs. Mac OS X host unmounts, backing file is closed, disk will not appear since no mount command can be issued, because the backing file is closed. Only if the gadget's "file" attribute in sysfs is written, or module is rmmod'ed & insmod'ed again will a mount command work. >> Fix this by adding a media_ejected flag to each lun, and keeping >> track of it properly. >> >> Any other method (i.e. preventing unmount, and not keeping track >> of the eject status) failed due to OS-X sending start stop commands >> after the unmount and checking again. > > NAK. This is definitely not the the right thing to do. > > Alan Stern > I'm open to suggestions that will make OS X behave in the same manner as Linux. Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
