Well, it's possible, but somewhat ugly. The real objection
I can see is that if you're optimizing this by, say, doing
DMA directly between the devices you may not actually have
the data to hand back to the caller or indeed know very
much about how much data you actually wrote out.
This is consistent with write(2), though. As I understand
it[*], if write returns an error, then under some circumstances
you are not guaranteed that none of the data was written.
Possibly the case, for example, for files where you run out
of disk space, or NFS where the server hit a Big Red Switch
Error half way through ...
So the fact that copy sometimes behaves unpredictable in
the presence of write errors ain't too much of a problem.
> > Update to my previous posting. I think the prototype should be:
> >
> > ssize_t copy (int from_fd, int to_fd, size_t *nbytes);
> >
> > so the kernel can return the number of bytes actually
> > copied in the event of an error. I'll try and implement
> > this some time and see if it's workable.
>
> It would be better to allow selecting offsets in both source and destination
> files.
What's wrong with lseek? Perhaps you misunderstand -- copy
is just a replacement for a loop with read + write -- so it
works from the current file position (if, indeed, the fds
refer to files at all).
Rich.
[*] My understanding may be at odds with reality :-)
-- Richard Jones rjones@orchestream.com Tel: +44 171 598 7557 Fax: 460 4461 Orchestream Ltd. 125 Old Brompton Rd. London SW7 3RP PGP: www.four11.com "boredom ... one of the most overrated emotions ... the sky is made of bubbles ..." Original message content Copyright © 1998- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu