Glad you got it resolved on your own. :-)
Here's a thought about a "more elegant" way than just delaying a few seconds. Have you tried using DiskArbitration.framework to unmount the disk instead of BSD unmount? Something like this: * DASessionCreate * DASessionScheduleWithRunLoop to add the session to a CFRunLoop * DADiskCreateFromBSDName * DADiskUnmount with kDADiskUnmountOptionForce and pass a callback routine. * Run the CFRunLoop and wait for the completion callback That completion callback may be a more reliable signal that it's safe to remount the disk. I don't know if it really guarantees anything about the order of events or not - the documentation is pretty minimal - but DiskArb is really the "official" mid-level API for unmounting and ejecting disks, and if there's anything that will properly wait until the disk is completely gone on OSX, DiskArb is probably it. -drew On Dec 21, 2008, at 8:07 PM, Luke wrote: > > Resolved (satisfactorily)... > > Well, it seems that I have to wait a certain amount of time between my > unmount request and any attempt to mount the new VFS. > It appears that it is sufficient to loop a few times starting a run > loop for fixed period (say 1 second) and then rechecking with the > Finder if the volume is unmounted when the run loop times out. > Perhaps there's a more elegant way of waiting the unmount to complete > (sufficiently for MacFUSE to have no problems re-mounting without the > "internal error"), but this works OK for now. > > -- lwe > > > On Dec 21, 12:21 pm, Luke <[email protected]> wrote: >> I've upgraded to 2.0.3. I haven't had the Finder 'no entry' folder >> behaviour since (though that might be unrelated). >> I do however have the problem that when my process starts up and >> discovers a dead FS, it unmounts it successfully, but then fails to >> mount the new FS in its place (I get the "internal fuse error" >> message). However, if this process is now terminated and I start >> the >> app again, then the new FS is correctly mounted. >> >> One possibility is that I might need to serialise my force unmounting >> and the attempt to mount the new file system dependent on some event >> (i.e. wait until Finder says the old dead FS is gone). At the >> moment, >> I attempt to mount the new FS right after unmount returns, and there >> may be some stuff asynchronous to the BSD unmount that needs to >> complete. >> >> On Dec 19, 2:35 pm, Luke <[email protected]> wrote: >> >>> Hello MacFusiliers, >> >>> I see there's been some discussion on forced unmounting (of 'dead' >>> filesystems), but I have some general questions. >> >>> I'm trying to make my app "do the right thing" when it comes to >>> orphaned filesystems. Clearly, it is possible for an abrupt >>> shutdown >>> of the app to leave its VFS orphaned (easily reproduced while >>> debugging too), and I figured it would at least be nice if the app >>> was >>> able to deal with this situation when restarted - i.e. force >>> unmount a >>> dead FS at the expected mount point, before recreating a new 'live' >>> VFS in its place. >> >>> The code I have written to do this, attempts to do the 'obvious' >>> thing. I'm using BSD's unmount with the MNT_FORCE option (which >>> seemed to be necessary). When the app tries to create a new VFS at >>> this location however, I get a number of behaviours: >> >>> 1. An 'internal error' from MacFUSE: >> >>> 19/12/08 1:49:58 PM XXX[23525] XXFilesystem unable to mount because: >>> Error Domain=GMUserFileSystemErrorDomain Code=1003 >>> UserInfo=0x1a292d0 >>> "Internal fuse error (rc=0) while attempting to mount the file >>> system. >>> For now, the best way to diagnose is to look for error messages >>> using >>> Console.", userInfo={ >>> NSLocalizedDescription = "Internal fuse error (rc=0) while >>> attempting to mount the file system. For now, the best way to >>> diagnose >>> is to look for error messages using Console."; >> >>> } >> >>> 2. Finder showing a folder with a no-entry decal at the mount point. >> >>> Reading the docs and comments, it seems that MacFUSE has a timeout >>> feature that may (eventually) automatically unmount 'dead' >>> filesystems, though I'm not sure I'm seeing this happen. Perhaps >>> timeout period does however affect the behaviour of MacFUSE when >>> attempts are made to forcibly unmount MacFUSE filesystems? >> >>> I guess I'm interested to know what the best practice would be for >>> handling this kind of situation. I'm using the latest MacFUSE 2.0, >>> and am on the latest Leopard (10.5.6). >> >>> Cheers >> >>> -- Luke > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
