Re: Remote copy on AFP volume
Re: Remote copy on AFP volume
- Subject: Re: Remote copy on AFP volume
- From: Jim Luther <email@hidden>
- Date: Mon, 21 Apr 2008 14:18:02 -0700
I'm sorry if I confused things for you.
FSCopyObjectSync/Async -- These File Manager routines will copy a
source object (file or directory) into the destination directory.
FSCopyObject will use PBFSCopyFileSync/Async if the source and
destination are on the same volume. These routines are available 10.4
and later.
PBFSCopyFileSync/Async -- These routines only work on volumes that
support the CopyFile system call (which can be determined from the
bHasCopyFile GetVolParms bit). The source and destination must be on
the same volume. These routines are available 10.5 and later.
The CopyFile system call is supported on AFP server volumes via the
FPCopyFile transaction and then, only if the server supports
FPCopyFile. The AFP file system on Mac OS X does not support copying
from a source to a destination on different volumes -- even if both
those volume are on the same server. You'll get EXDEV if the volumes
of the source and destination are different. I have no idea if the
CopyFile system call is public.
If FPCopyFile is supported by an AFP file server, it probably supports
cross-volume copies since that's part of the AFP protocol. However,
since the AFP file system on Mac OS X doesn't support cross-volume
copies, do you *really* want to write all of the code needed to login
to the server, open the volumes, and copy the file? I wouldn't.
- Jim
On Apr 21, 2008, at 12:34 PM, James Bucanek wrote:
Jim Luther <mailto:email@hidden> wrote (Monday, April 21, 2008
11:36 AM -0700):
The File Manager copy functions (and BSD level copy functions) on Mac
OS X do not take advantage of the AFP protocol's ability to tell a
server to copy between two different volumes as long as they're on
the
same server. So the AFP protocol allows it, but it's not used. Pre-
Mac
OS X system software took advantage of this protocol feature, but in
practice the UI around it didn't work very well with large files
because there's no feedback from the server during an AFP copy
operation.
OK, now I'm confused. Quinn wrote
FSCopyObject does not go through <x-man-page://3/copyfile> but it
will
use the copyfile system call under some circumstances.
Specifically, it
requires that the source and destination volumes are the same and the
volume supports copyfile per the VOL_CAP_INT_COPYFILE flag returned
by
<x-man-page://2/getattrlist>. Notably, AFP actually allows you to
copy
between two different volumes as long as they're on the same
server, but
FSCopyObject does not take advantage of that.
... which implies that the copyfile system call will automatically
instruct the file server to perform the copy locally. So
FSCopyObjectSync should work on both Tiger and Leopard. Or is the
copyfile system call Leopard only too?
Assuming it is, it looks like I should be doing this
if (PBFSCopyFileSync!=NULL) // Leopard?
use PBFSCopyFileSync
else
if (source on AFP volume)
use FPCopyFile
else
use FSCopyObjectSync
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden