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. _______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol