The problem I have is that I am using
file:///Volumes/Drive/Folder/File style URLs to pass pointers to
files over a network connection. When I use CFURL to resolve a URL
like:
file:///Volumes/G4_HD/folder/file
As you can see, this is an inherently fragile way to do things.
Even without
the bug discussed above, I can't recommend this as a way to go.
We need to pass around a file specification via TCP/IP between
various different applications working on the same file from
different computers. The file spec also has to go through an asset
management system which needs to store the location as (unicode)
text, then pop out the other side and be picked up again.
What better mechanism would you recommend instead to identify a
file which resides on a shared volume in a workgroup ?.
The file is uniquely identified by two things; the share identifier
tuple (machine,sharename) and the share-relative path. Your current
scheme makes the (unreliable) assumption that a given share will
always be mounted at the same local path but (as you have discovered)
offers no guarantee of that.
A more robust approach would be to pass around the share identifier
and the share-relative path, and then on each client system translate
the share identifier into a local path at the time of use. This
would also facilitate (re)connecting to the share if it's not
currently mounted.
One additional point to consider; the share mounted in /Volumes is
nominally under the control of the user. If robustness is important
to you (and user navigation of the mounted share less so) you might
consider having your application explicitly mount the share somewhere
else where it can guarantee the local path translation for a given
network share.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
