Chiming in because I also had rename-related investigations (I don't
think this answers the original question but it is relevant to the
response):
- smbclient does SMB1 rename using cifs rename, not using FILE_RENAME_INFO
- so does Windows (or so it seems)
- smbclient can be made to use FILE_RENAME_INFO using the -f option
- however, the -f implementation for NT1 is broken because NT1 expects
the dest file to be relative to directory of source file, and cannot
move it to another dir (SMB2 onwards expects the dest to be relative to
share's root and *can* move file between dirs
The attached patch set to Samba includes a torture test that
demonstrates all that (passes against both Samba and Windows 10)
Thanks,
Uri.
On 10/25/2017 10:18 PM, Sreekanth Nadendla via cifs-protocol wrote:
> Hello Andreas, in the sample traces you've sent us, I can see the setInfo
> request with SMB2_FILE_RENAME_INFO for SMB2 case. However I don't see similar
> rename structure from your first trace rename_nt1. Let me know if I'm
> missing something.
>
> On windows OS, rename command does not allow you to specify a new drive
> (device) or *path* for the destination file. Before I dig in further with
> "move" command in my investigation, I would like to see from your traces
> exactly how the request was sent to server in the case of SMB v1. Also if
> you can, please confirm if the same Windows 2012 server is used when your
> client was using SMB v3.
>
>
> Regards,
> Sreekanth Nadendla
> Microsoft Windows Open Specifications
>
> -Original Message-
> From: Sreekanth Nadendla
> Sent: Friday, October 20, 2017 11:16 AM
> To: Andreas Schneider
> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
> Subject: [REG:117102016529426] SMB2 File Rename
>
> Hello Andreas, I will be assisting you with your issue. I am currently
> researching the problem and will provide you with an update soon. Thank you
> for your patience.
>
> Regards,
> Sreekanth Nadendla
> Microsoft Windows Open Specifications
>
> -Original Message-
> From: Andreas Schneider [mailto:a...@samba.org]
> Sent: Friday, October 20, 2017 6:21 AM
> To: Interoperability Documentation Help
> Cc: cifs-protocol@lists.samba.org
> Subject: SMB2 File Rename
>
> Hello,
>
> I disovered that a file rename operation (SetInfo with
> FILE_RENAME_INFORMATION_TYPE_2) fails for a SMB3 connection but works for
> SMB1.
>
> I've run smbclient from Samba again Windows 2012:
>
> File rename (move) over SMB1 with smbclient:
>
> bin/smbclient //win-dc02.earth.milkyway.site/Test -Ubob1%Secret007! -mNT1 Try
> "help" to get a list of possible commands.
> smb: \> cd dir1
> smb: \dir1\> rename README ..\dir2\README
> smb: \dir1\>
>
> This works!
>
> File rename (move) over SMB3 with smbclient:
>
> bin/smbclient //win-dc02.earth.milkyway.site/Test -Ubob1%Secret007! -mSMB3
> Try "help" to get a list of possible commands.
> smb: \> cd dir1
> smb: \dir1\> rename README ..\dir2\README NT_STATUS_OBJECT_NAME_NOT_FOUND
> renaming files \dir1\README -> \dir1\..
> \dir2\README
> smb: \dir1\>
>
> As you can see, it fails with NT_STATUS_OBJECT_NAME_NOT_FOUND.
>
> I do not see that we're doing anything wrong in the SetInfo request. The doc
> does not mention that '..' is not allowed.
>
> Is a path of dir1\..\dir2\file not allowed?
>
>
> Attached are the network traces.
>
>
> Thanks for your help!
>
>
> Best regards,
>
>
> Andreas
>
>
From c5c185f510eee0729b5b6abeb5209c89ac3537fd Mon Sep 17 00:00:00 2001
From: Uri Simchoni
Date: Thu, 7 Sep 2017 18:12:25 +0300
Subject: [PATCH 1/3] cli: add low-level synchronous NT1 rename
Add a synchronous function that invokes rename via
FILE_RENAME_INFORMATION passthrough, in the NT1
dialect. This adds on the async version that already
exists, and is meant for use by torture tests.
Signed-off-by: Uri Simchoni
---
source3/libsmb/clifile.c | 47 +++
source3/libsmb/proto.h | 4
2 files changed, 51 insertions(+)
diff --git a/source3/libsmb/clifile.c b/source3/libsmb/clifile.c
index a6a0baf..548c99e 100644
--- a/source3/libsmb/clifile.c
+++ b/source3/libsmb/clifile.c
@@ -1094,6 +1094,53 @@ fail:
return tevent_req_post(req, ev);
}
+NTSTATUS cli_smb1_rename(struct cli_state *cli,
+ const char *fname_src,
+ const char *fname_dst,
+ bool replace)
+{
+ TALLOC_CTX *frame = NULL;
+ struct tevent_context *ev;
+ struct tevent_req *req;
+ NTSTATUS status = NT_STATUS_OK;
+
+ if (smbXcli_conn_protocol(cli->conn) >= PROTOCOL_SMB2_02) {
+ return NT_STATUS_INVALID_PARAMETER;
+ }
+
+ frame = talloc_stackframe();
+
+ if (smbXcli_conn_has_async_calls(cli->conn)) {
+ /*
+* Can't use sync call while an async call is in flight
+*/
+ status = NT_STATUS_INVALID_PARAMETER;
+ goto fail;
+ }
+
