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 -~----------~----~----~----~------~----~------~--~---
