rename of hardlinked files

[Jeremy Allison]

On Thu, May 27, 2004 at 10:44:11PM -0500, Steven French wrote:
> 
> One of the connectathon POSIX file subtests does a rename of fileA to fileB
> where fileA and fileB are hardlinked.   For POSIX this is supposed to be a
> noop, but Samba (and Windows) return STATUS_NAME_COLLISION which causes the
> Linux cifs client (which does not realize that they are hardlinked) to
> delete the target and retry the rename.   Since the rename smb op (and the
> SMB NT Rename as well) only have a 16 bit attributes field passed on the
> request, it does not look like the trick of passing ATTR_POSIX_SEMANTICS
> would work (since it is an attribute flag in the range above 64K which can
> only be passed in 32 bit attribute fields such as what NTCreate allows).
> 
> Ideas?

Hmmm. A new UNIX_RENAME call ?

> Negotiating a posix dialect would work for Samba to be able to respond
> differently (such code for negotiating a new dialect is ifdef out currently
> in the 2.6.7pre Linux CIFS client), but there may be a better way - I might
> be able to save off Samba's inode number (returned on UNIXQPathInfos - but
> can it be relied upon to match when returned over the existing CIFS Unix
> extensions?) and compare after the failure - but it could add to the size
> of the existing inode struct which would be expensive in memory on the
> client (lots of inode structs get cached).

Yes the inodes will match as they are read directly off
the disk on the server. They are normal UNIX inodes mapped
into a 64 bit field.

Jeremy.