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

[Ihar 'Philips' Filipau]

jw schultz wrote:
> 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.

  So it was my point - without flink() IMHO it makes no sense.

  Just try to imagine any application for sys_copy(char*,char*).
  None _I_ _can_ imagine.

  "int new_fd = sys_copy( old_fd );" make sense to me - but you need to 
have counter-part of it - "flink();" - to commit it to file system.

   You really do not need a copy of a file just for copy of a file.
   That's what hard link is for.

   My way vim/emacs can:

   fd = open("originalfile");
   new_fildes = copy(fd);
   close(fd);
    ... [do the editing] ...
   flink(new_fildes, "newfile"); /* if user decides to save this job */
   close(new_fildes);

   This make sense - and this is the way usually we do processing of 
information. Mimicing cp - is really bad example.

   I have re-read thread. I see flink() not as security hole - but they 
use should be managed in some way.

   Original thread about flink() - everthing doable.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=20030406190025%241ec6%40gated-at.bofh.it&rnum=50&prev=/&frame=on
   And there was no real security issue given whatsoever.
   Only design considerations ;-)

> So if you can do it with open file descriptors why do you
> need a new system call?

  The point, that different fs's can optimize this as they wish.
  This would be really nice thing to have in our networked age.

  Sshing just to copy huge file - is little bit annoying ;-)

P.S. actually my mind keeps spining idea of cut()/paste(). So file 
descriptor without assoc. file path can be useful.
Say:

   -----------
   fd_part_1 = open("some file");
   seek(fd_part_1, 100, 0);
   fd_part_2 = cut( fd_part_1 );  /* XXX */
   /* here eof(fd_part_1) == 1 && "some file" is truncated to 100b. */

   flink(fd_part_2, "second part"); /* create file
                   with rest of "some file" */
   -----------
   fd_part_1 = open("some file");
   fd_part_2 = open("second part");
   paste(fd_part_1, fd_part_2);   /* XXX */
           /* fd_part_2 is auto close()d
              and "second part" file unlinked */
   close(fd_part_1);
   /* here "some file" will be the same as in the begining */
   -----------

   This should help video/audio editing much.

P.P.S. not relevant but in any way SUSv3 docs for fattach()
http://www.opengroup.org/onlinepubs/007904975/functions/fattach.html


--
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--                                                           _ _ _
 "... and for $64000 question, could you get yourself       |_|*|_|
   vaguely familiar with the notion of on-topic posting?"   |_|_|*|
                                -- Al Viro @ LKML           |*|*|*|

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/