Re: OT: why no file copy() libc/syscall ??

[Jesse Pollard <jesse@cats-chateau.net>]

On Monday 10 November 2003 09:19, David Woodhouse wrote:
> On Mon, 2003-11-10 at 07:29 -0600, Jesse Pollard wrote:
> > > > sys_fscopy(...)
> >
> > It is too simple to implement in user mode.
>
> Is it? Please explain the simple steps which cp(1) should take in order
> to observe that it is being asked to duplicate a file on a file system
> such as CIFS (or NFSv4?) which allows the client to issue a 'copy file'
> command over the network without actually transferring the data twice,
> and to invoke such a command.

Ah. That is an optimization question, not a question of kernel/user mode.

Since the error checking for source and destination both include doing
a stat and statfs, the device information (and FS info) can both be retrieved.

And mmap doesn't require data transfer "twice" (local copy). Since that copy 
only pagefaults (though read/write may be faster for some files - I thought
that was true for small files that fit in cache, and large files faster via
mmap and depends on the page size; and the tradeoff would be system
dependant).

And since both source and destination may be remote you do get to decide
based on source and destination devices: if they are the same, and one on
a remote node, then BOTH will be on the remote, then you get to use the
CIFS/NFS file copy. (check the doc on "stat/statfs" for additional info).

I don't believe it works when source and destination are on DIFFERENT remote
nodes, though.

Strictly up to the implementation of cp/mv.

Though you will loose portability of cp/mv. (Of course, you also loose
it with a syscall for file copy too; as well as the MUCH more complicated
implementation/security checks).