lkml.org 
[lkml]   [2003]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OT: why no file copy() libc/syscall ??
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.044 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site