Hi Alan, On May 23, 2012, at 7:20 PM, Alan Stern wrote: > On Wed, 23 May 2012, Pantelis Antoniou wrote: > >> 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. > > Okay. It has every right to do so. > >>>> 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. > > Yes, that all sounds right. > >> I'm open to suggestions that will make OS X behave in the same manner as >> Linux. > > Then may I suggest that you write to the developers at Apple and send > them your advice? Clearly nothing we do here in the linux-usb mailing > list will change OS-X's behavior. :-) > I'm pretty sure our chances of changing what they do is nil. > Seriously, if the host OS sends an eject command then we have to assume > that this is what the user really wants. Suppose that instead of a > mass-storage gadget, an actual USB storage device had been plugged in, > like one of the old ZIP drives. When OS-X sends it an eject command, > it will eject its cartridge. After that, no mount command will work > until the user puts a new cartridge in the drive. That's exactly how > the mass-storage gadget behaves. > > Of course, you always have the option of not specifying the > "removable=y" module parameter when loading the gadget originally. > Without that parameter, the backing file won't get closed when the > eject command is received. > Unfortunately this has been tried, and what it does is canceling the unmount. So the disk remains perpetually mounted. > Alan Stern > It is what it is then. It is very bad from a user perspective. Any chance to have a module parameter that selects this behavior, with it being defaulted to no? 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
