Re: [PATCH 4/4] copyfile: copyfile

[Steve French <smfltc@us.ibm.com>]

On Tue, 2004-09-07 at 09:06, Linus Torvalds wrote:
> For cifs to be able to use it, the "copyfile()" interface needs to
> basically just be a pathname operation (ie a "dir->i_op->copy()"), not a
> "struct file" operation.  It's more like the VFS "->rename()" or "->link"
> operations, in other words. And it should return -EXDEV the same way
> rename returns EXDEV if the files aren't on the same filesystem.
>
> I think you should be able to copy the "sys_link()" code for almost all of 
> the top-level stuff. The only real difference being
> 
> -	error = dir->i_op->link(old_dentry, dir, new_dentry);
> +	error = dir->i_op->copy(old_dentry, dir, new_dentry);
> 
> answer may be that filesystems that don't support this as a "native op"  
> and can't do it quickly should just return an error, and then users can
> copy their multi-gigabyte files by hand, like they used to.

Yes - the CIFS protocol operation for copy requires syntax similar to
the link or rename examples.  The protocol operation for CIFS copy
requires:
1) a source filename (and a tree identifier - which identifies which
server export ie share the path is relative to)
2) a target filename (and target tree identifier)
3) source and target on the same server - The client filesystem can
enforce the last requirement that the source and target be on the same
server (although some servers also will reject it if the source and
target are not on the same filesystem on the same server) by simply
returning EXDEV to the VFS if the source and target are on different
servers.

Using a similar i_op to the link i_op contains sufficient information
for me to turn on the CIFSSMBCopy function in the fs/cifs code.

There are a couple of obvious copy options which probably could be
mapped onto the cifs network protocol but are not required.
4)Something like a "FAIL_IF_EXISTS" flag (do not copy the file if the
target file exists)
5) a "copy subtree" flag indicating whether the copy is for the
file/directory or for the whole subtree. 

As in link, returning an error when the filesystem can not perform the
operation should be expected by the layers above.

Defining a handle (file struct) based copy operation is not as useful. 

I believe that as a result of the copy request that most CIFS servers
typically would copy file attributes (such as in the case of cifs
servers the dos attributes) and extended attributes (xattrs, and NTFS
alternate data streams if the server supports them) but ACLs for the
existing file would not be copied to the new file.  That seems like
reasonable default common sense semantics. Allowing the client to
interrupt a network file copy that has been submitted to the server will
not always be possible, but it is at least easier to preserve atomicity
in the case of a single copy operation going over the network than it
would be if the copy is broken apart by the client and as individual
open/read/close open/write/close