[cifs-protocol] [REG:117050715700170] SMB1 processing of FileRnameInfo

[Uri Simchoni]

On 05/17/2017 11:09 PM, Bryan Burgin wrote:
> Concurrently, after shifting focus from the Win32 API question, I found our validation code on the server side.  We have code that " If there are any path separators in the name, then we do not support this operation."
> Are you sure about " That means rename+replace in SMB1 is limited to dest being at the root of the share."?  It seems that if the CreateFile was against "dir\anotherdir\filename.txt" and you just included "newname.txt" in the tunneled rename, it would work.  In other words, all the path info is in the original CreateFile call.  Can you test that as I don't have the environment (an environment that can emit the request from a client)?
> 
> Bryan

Confirmed. It appears as though in SMB1, the destination is relative to
the source file (thereby allowing rename in the same directory, any
directory), whereas with SMB2, the destination is relative to the root
of the share (and supporting move between directories).

If that's correct, then [MS-FSCC] is in error, as 2.4.34.1 says:

"...For network operations, this pathname is relative to the root of the
share"

BTW, Samba also works that way (SMB1 server interprets the destination
as relative to source's parent directory, SMB2 server interprets the
destination as relative to the share's root. Somehow we got that right
although we don't seem to have torture tests to prove it.

Seems like I need to fix my recent addition of "-f" flag to smbclient
rename command.

Thanks for helping me clear this up,
Uri.