Thanks Drew - I'll take a look at this.
On Dec 21, 5:34 pm, Drew Thaler <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
