Re: mount() from Cocoa App
Re: mount() from Cocoa App
- Subject: Re: mount() from Cocoa App
- From: Dalton Hamilton <email@hidden>
- Date: Fri, 28 Oct 2005 13:32:15 +0200
About a week ago, you guys helped me with a SMB/AFP mount question.
I had a follow-up question and I posted this to the cocoa-dev mail
list a couple days ago and got no response. However, since you guys
are the one that gave me the idea, I hope it isn't in-appropriate to
ask this question here.
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???
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???
Thanks.
-----------------------------------------------------------------
Dalton Hamilton
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