Content-Type: text/plain;
  charset="CP 1252"
From: Jesse Pollard <jesse@cats-chateau.net>
To: Florian Weimer <fw@deneb.enyo.de>
Subject: Re: OT: why no file copy() libc/syscall ??
Date: Thu, 20 Nov 2003 13:08:17 -0600
Cc: Valdis.Kletnieks@vt.edu, Daniel Gryniewicz <dang@fprintf.net>,
       linux-kernel mailing list <linux-kernel@vger.kernel.org>
References: <1068512710.722.161.camel@cube> <03111209360001.11900@tabby> <20031120172143.GA7390@deneb.enyo.de>
In-Reply-To: <20031120172143.GA7390@deneb.enyo.de>
MIME-Version: 1.0
Message-Id: <03112013081700.27566@tabby>
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2341
Lines: 50

On Thursday 20 November 2003 11:21, Florian Weimer wrote:
> Jesse Pollard wrote:
> > > > 	int sys_copy(int fd_src, int fd_dst)
> > >
> > > Doesn't work.  You have to set the security attributes while you open
> > > fd_dst.
> >
> > Why? the open for fd_src should have the security attributes (both
> > locally and in the file server if networked). Opening fd_dst should SET
> > the security attributes desired (again, locally and in the target
> > fileserver).
>
> The default attributes in the new location might be less strict than the
> attributes of the source file.

So what. the user was authorized to open the input file. The user was
authorized to open the output file. A file copy should be possible remotely
since the equivalent implementation of a local read/write loop would
accomplish the same thing.

> If sys_copy() is just an API to introduce a new copy-on-write hard link,
> these problems disappear.  They are only relevant if sys_copy() is
> intended to be a generic "copy that file" interface.

Now if you wanted the remote server to deny the network copy... could
be done - after all the credentials for both input and output files
are present on the server. If the server decides NOT to copy, then fine.
It would just cause the user to make the copy with a read/write loop.

I was only thinking of it as a way to gain access to any filesystem
support that may be available for copying files. If none is available,
then do it in user mode.

Personally, I'm not sure it is a good idea, partly because the semantics
of a file copy operation are not well defined (some of the following IS 
known).

1. what happens if the copy is aborted?
2. what happens if the network drops while the remote server continues?
3. what about buffer synchronization?
4. what errors should be reported ?
5. what happens when the syscall is interupted? Especially if the remote
   copy may take a while (I've seen some require an hour or more - worst
   case: days due to a media error (completed after the disk was replaced)).
6. what about a client opening the copy before it is finished copying?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/