Re: mount() from Cocoa App
Re: mount() from Cocoa App
- Subject: Re: mount() from Cocoa App
- From: "Philip D. Wasson" <email@hidden>
- Date: Fri, 28 Oct 2005 16:47:43 -0400
On Oct 28, 2005, at 07:32, Dalton Hamilton wrote:
I am using FSMountServerVolumeAsync and FSUnmountVolumeSync to mount
and unmount smb and afp shares.
QUESTION 1:
However, I don't see a way to detect if the user has mounted the
shared volume manually. If the user has mounted the share manually
and then he runs my application and clicks on the button to mount the
same shared volume, my application calls FSMountServerVolumeAsync and
a second volume (icon is a Globe) appears on the desktop for the same
shared volume. However, If the volume was mounted by my application
and then the user attempts to mount the volume again, the applications
FSMountServerVolumeAsync operation provides an error code (to my
callback function) of volOnLinErr -- which means Volume is already
online. I don't see the connection. Why doesn't the
FSMountServerVolumeAsync operation give the same volOnLinErr when the
volume has been mounted already manually???
We do something similar in a few of our apps (all Carbon). To see if
the desired volume is already mounted, we start by iterating through
all mounted volumes using the Carbon File Manager call
PBHGetVInfoSync() in indexed mode; that gets each valid volume
reference number. For each, we call PBGetVolMountInfo() to get the
remote mounting info and compare the values therein with what we're
looking for (you'll get an error for local volumes). That works fine
for AFP shares, not so much for SMB. For those, we then call
FSCopyURLForVolume() and extract the host name using
CFURLCopyHostName() and compare to the desired one. That can get messy
depending on whether what you're looking for is a host name or IP
address. The worst example of that is where there's no domain server
available for local machines, so you're looking for an IP address, but
somehow the file sharing client gets the host name from the host during
its connection, so when you call FSCopyURLForVolume(), a host name
comes back instead of an IP address. And you can't even get around it
by looking up the name for the IP address you have and also comparing
that name, or by looking up the address for the name you got back and
comparing that, because there's no domain name server. Hopefully you
don't run into that.
QUESTION 2:
Likewise, I'd like to be able to un-mount manually mounted volumes.
Today, when my application mounts a shared volume, I save the volume
reference number. I pass this volume reference number to the
FSUnmountVolumeSync call and it un-mounts the volume. How do I detect
the manually mounted share and get its volume reference number???
Using the above-described method, you get the volume reference number,
which you can save and use to unmount it later. But I bet you figured
that out already, huh?
On Oct 18, 2005, at 12:02 AM, Jim Luther wrote:
On Oct 17, 2005, at 2:18 PM, Quinn wrote:
My general advice for dealing with timeouts is to use an infinite
timeout and provide the user with status and a way to cancel. That
way, if the user has kicked out their network cable (or is on the
wrong AirPort network, or whatever), they get a chance to rectify
that problem without you artificially timing out. You should only
use a specific timeout if it's not appropriate to provide a cancel
button (for example, you're a server).
Implementing this philosophy for server mounting is easy because
Apple provides you with a cancel call (FSCancelVolumeOperation).
I missed the obvious answer... That's what I get for answering
questions after being away from DTS for 10 years :-)
However, I looked at what FSCancelVolumeOperation does in this case
(since I recently worked on the framework below it) and there's an
edge case that's worth mentioning...
FSCancelVolumeOperation indirectly causes a kill(2) on the mount
process. If the mount process completes just as your
FSCancelVolumeOperation call comes in, the results cannot be
determined:
* If you get an error back from FSCancelVolumeOperation (probably an
ioErr) then the mount process has probably already completed and the
volume should be mounted.
* If you get no errors back from FSCancelVolumeOperation, then you
killed the mount process and the volume MAY OR MAY NOT be mounted --
it depends on if the mount command has called mount(2) to mount the
volume or not. If mount(2) has completed successfully, then the
volume should be mounted. If mount(2) has not completely
successfully, then the volume should not be mounted.
- Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
----------------------------------------------------------------------
Philip D. Wasson pwasson at maned dot com
Software Engineer Managing Editor Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden