Messages in this thread | | | Date | Tue, 11 Nov 2003 02:41:10 -0800 | From | jw schultz <> | Subject | Re: OT: why no file copy() libc/syscall ?? |
| |
On Tue, Nov 11, 2003 at 10:51:10AM +0100, Ihar 'Philips' Filipau wrote: > 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) > > > > > >Doesn't work. You have to set the security attributes while you open > >fd_dst. > > int new_fd = sys_copy( int src_fd ); /* cloned copy, out of any fs */ > fchmod( new_fd, XXX_WHAT_EVER ); /* do the job. */ > ... > flink(new_fd, "/some/path/some/file/name"); /* commit to fs */
The associate open file descriptor with a new path system call (flink here) has already been rejected for solid security reasons.
> close(new_fd); /* bye-bye */ > > I beleive this can be more useful. Not only in naive tries to replace > cp(1) with kernel ;-)
Eliminating the flink and using file descriptors you wind up with something like:
in_fd = open(oldpath, O_RDONLY); fstat(in_fd, statbuf); out_fd = open(newpath, O_WRONLY|flags, statbuf->st_mode); sendfile(out_fd, in_fd, 0, statbuf->st_size); close(out_fd); close(in_fd);
So if you can do it with open file descriptors why do you need a new system call?
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws
Remember Cernan and Schmitt - 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/
| |