Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: OT: why no file copy() libc/syscall ?? | From | Justin Cormack <> | Date | 20 Nov 2003 19:44:13 +0000 |
| |
On Thu, 2003-11-20 at 19:08, Jesse Pollard wrote: > Now if you wanted the remote server to deny the network copy... could > be done - after all the credentials for both input and output files > are present on the server. If the server decides NOT to copy, then fine. > It would just cause the user to make the copy with a read/write loop. > > I was only thinking of it as a way to gain access to any filesystem > support that may be available for copying files. If none is available, > then do it in user mode. > > Personally, I'm not sure it is a good idea, partly because the semantics > of a file copy operation are not well defined (some of the following IS > known). > > 1. what happens if the copy is aborted? > 2. what happens if the network drops while the remote server continues? > 3. what about buffer synchronization? > 4. what errors should be reported ? > 5. what happens when the syscall is interupted? Especially if the remote > copy may take a while (I've seen some require an hour or more - worst > case: days due to a media error (completed after the disk was replaced)). > 6. what about a client opening the copy before it is finished copying?
If you really want a filesystem that supports efficient copying you probably want it to have the equivalent of COW blocks, so that a copy just sets up a few pointers, and the copy only happens when the original or copied files are changed.
But basically you wont get a syscall until you have a filesystem with semantics that only maps onto this sort of operation.
Justin
- 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/
| ![\](/images/icornerr.gif) |