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

[jw schultz <jw@pegasys.ws>]

On Tue, Nov 11, 2003 at 09:58:06AM +0100, Florian Weimer wrote:
> Andreas Dilger wrote:
> 
> > > This is fast turning into a creeping horror of aggregation.  I defy anybody
> > > to create an API to cover all the options mentioned so far and *not* have it
> > > look like the process_clone horror we so roundly derided a few weeks ago.
> > 
> > 	int sys_copy(int fd_src, int fd_dst)

That sounds a lot like a sendfile with a file as the
destination.  Useful but still happening on the local system.
My understanding was that this was to be sent to a remote
system where the file descriptors might not be open.

> 
> Doesn't work.  You have to set the security attributes while you open
> fd_dst.

That would have been done with open().

To operate on paths so it could be sent to a fileserver it
would need the same arguments as open() with the addition of
the newpath.

	int sys_copy(const char *oldpath, const char *oldpath,
	    int flags, mode_t mode);

O_TRUNC		replace an existing file.
O_EXCL		prevent replacing an existing file.
O_APPEND	concatenate (useful feature creep).
O_NDELAY/O_NONBLOCK	return and ignore ENOSPACE condition, ick!
O_SYNC		if O_SYNC supported for open
O_NOFOLLOW	don't follow symlink (no need for a lcopy())

EXDEV (see link(2)) seems a better error code for cases
where the source and destination are on different servers.
Otherwise the error codes would conform to open(2).

I've long thought a file copy syscall was missing from unix
but until you start networking it isn't an issue.



-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt