Messages in this thread | | | Date | Thu, 27 Nov 2003 11:02:17 +0100 | From | Jörn Engel <> | Subject | Re: OT: why no file copy() libc/syscall ?? |
| |
On Thu, 27 November 2003 01:50:46 -0800, David Lang wrote: > > > > I don't think it should do any linking / unlinking it should just work > > with file descriptors. Concurrent writes to a file don't have many > > guarantees. sys_copy shouldn't have to be any stronger (read weaker). > > I'm thinking that it may actually be easier to do this via file paths > instead of file descripters. with file paths something like COW or > zero-copy copy can be done trivially (and the kernel knows the user > credentials of the program issuing the command and can pass them on to the > filesystem to see if it's allowed). I don't see how this can be done with > file descripters (if all you have is a file descripter you can truncate > and write a file, but you don't know all the links to that file so you > can't reposition that first inode for example).
And how is userspace supposed to protect itself from race conditions? Just compare:
fd1 = open(path1); if (stat(fd1) looks fishy) abort(); fd2 = open(path2); if (stat(fd2) looks fishy) abort(); copy(fd1, fd2);
and:
fd1 = open(path1); if (stat(fd1) looks fishy) abort(); fd2 = open(path2); if (stat(fd2) looks fishy) abort(); copy(path1, path2);
Jörn
-- Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. -- Howard Aiken quoted by Ken Iverson quoted by Jim Horning quoted by Raph Levien, 1979 - 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/
| |