Re: [cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]

2016-08-11 Thread Uri Simchoni via cifs-protocol
Hi Obaid, I (hopefully) did as requested. I'd like to thank you for bearing with me on this one, this is much appreciated. Thanks, Uri. On 08/11/2016 09:33 PM, Obaid Farooqi wrote: > Hi Uri: > You must have received an email about creation of a workspace with > credentials to login. Please

Re: [cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]

2016-08-11 Thread Uri Simchoni via cifs-protocol
Hi Obaid, I'm still confused about the copychunk behavior. Let me reiterate what I understand, and then try to explain what I don't understand. 1. At the time of open, if the desired access included FILE_EXECUTE, then an SMB2 server would add FILE_READ_DATA to the granted access rights - this

Re: [cifs-protocol] [REG:116091614680032] [MS-SMB] - status code of NT_TRANS_QUERY_QUOTA

2016-09-21 Thread Uri Simchoni via cifs-protocol
Thanks! Uri On 09/21/2016 08:54 PM, Bryan Burgin wrote: > Hi Uri, > > I verified your findings and files an issue against [MS-SMB]. Requested > change: > > Update [MS-SMB] 3.3.5.11.2 "Receiving an NT_TRANS_QUERY_QUOTA Request" to > reflect: > > Send STATUS_BUFFER_TOO_SMALL if no buffer was

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

2017-05-17 Thread Uri Simchoni via cifs-protocol
Back to my client code - - Both smbclient and my modified smbtorture3 RENAME test use a leading '\' in file name. BTW, SMB2 and later, that leading '\' is cleared by the client library, that is - the application requests '\file'. - When I remove the leading '\', it worked as you predicted. - When

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

2017-05-09 Thread Uri Simchoni via cifs-protocol
On 05/09/2017 09:38 PM, Bryan Burgin wrote: > After carefully reading your text, I won't need your program. > I'll see if there is a different way to make a client send the > FileRenameInfo/Passthru command. > B. > FWIW, program attached. (notice that paths are hard-coded and files are assumed

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

2017-05-18 Thread Uri Simchoni via cifs-protocol
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

[cifs-protocol] SMB1 processing of FileRnameInfo

2017-05-07 Thread Uri Simchoni via cifs-protocol
Hi, I tried renaming files over SMB1 protocol using pass-through info-level of FileRenameInfo (cf [MS-SMB] 2.2.2.3.5). When doing this against a Windows 2012R2 machine, it fails with STATUS_NOT_SUPPORTED. The advantage of using FileRenameInfo instead of using SMB Rename would be that if the

Re: [cifs-protocol] [REG:117102016529426] SMB2 File Rename

2017-10-25 Thread Uri Simchoni via cifs-protocol
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