Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Hi Bill, I have done some more investigation on this issue, particularly around doing a Trans2SetPathInfo() with the documented FileEndOfFileInformation (0x104) level. It returns what I would expect to be an acceptable error for an unknown info level. I have attached a trace that shows this being done against a win7 server, but I have a question about what the server is returning. The packets of interest are 39/40: 1. Packet 40 appears to have the WordCount and ByteCount truncated, making the packet smaller than normal minimum size of 35? Is this intended behavior that other servers should implement? Additionally a DOS Error is returned instead of a standard NT_STATUS error. MS-CIFS does say that a DOS error or an NT_STATUS error may be returned, but I don't see any indication in the documentation of when a DOS error should be returned instead of an NT_STATUS error. Is it possible to make this explicit in the docs or is this a case where it's purposefully left ambiguous? Thanks! -Tim On Nov 25, 2009, at 11:13 AM, Bill Wesse wrote: Question: Which existing handle would the pass-through be using? The handle opened in packet #28 is a separate tcp connection and a separte session from the Trans2SetPathInfo in packet #33. I'm not aware of any situation where the server is expected to share file handles across multiple sessions. Is this an exception? Response: I was paying more attention to the PID (0x26CD) - and didn't drill down closer to the sessions (both of which use the same security principal). Thanks for pointing that out; I will take it into account during my ongoing study (this implies a straight share mode bypass). Question: If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Response: That is certainly one of my goals - as I noted in my recent response to Jeremy, I intend to set up test code to exercise the information levels against the SMB calls. As I also mentioned, I will submit a TDI against this - before starting on any test code. Also, the best reference for the full roster of info levels is at: MSDN WDF_FILE_INFORMATION_CLASS http://msdn.microsoft.com/en-us/library/dd568296.aspx this being a subset: [MS-FSCC] 2.4 File Information Classes http://msdn.microsoft.com/en-us/library/cc232064.aspx Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Wednesday, November 25, 2009 1:21 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi Bill, Thank you for the quick answer! I have a few comments/questions below. On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote: Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. Which existing handle would the pass-through be using? The handle opened in packet #28 is a separate tcp connection and a separte session from the Trans2SetPathInfo in packet #33. I'm not aware of any situation where the server is expected to share file handles across multiple sessions. Is this an exception? I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through value), since that requires the file handle (per [MS- CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx) . I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the same session would have succeeded. -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Good morning Tim. Bill Wesse from the Documentation Support team here. I will be your contact for this issue. We have created the following case to track our investigation: SRX091124600335 [MS-SMB] Trans2SetPathInfo() not enforcing share mode I will begin work this morning, and will update you with status before the end of the day. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Tuesday, November 24, 2009 6:07 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi, Based on the ZwSetInformationFile() docs (http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file. The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? I have attached a pcap of a client executing these exact steps against a win7 server. Packet 27/28: Step 1 Packet 29/30: Step 2 Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced. Thanks! -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through value), since that requires the file handle (per [MS-CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx). SMB_INFO_PASSTHROUGH levels request a native Windows NT operating system information level (as you already have noted) of the TRANS2_SET_* TRANS2_QUERY_* calls, and can be thought of as rough equivalents to ZwSetInformationFile and ZwQueryInformationFile: 1. Where the 'FILE_INFORMATION_CLASS FileInformationClass' parameter is equal to: (InformationLevel - SMB_INFO_PASSTHROUGH) : See MSDN WDF_FILE_INFORMATION_CLASS at http://msdn.microsoft.com/en-us/library/dd568296.aspx 2. The InformationLevels are restricted as noted in: [MS-SMB] 6 Appendix A: Product Behavior 158, 239, 240 and 242 at http://msdn.microsoft.com/en-us/library/cc246806.aspx [MS-FSCC] 5 Appendix A: Product Behavior note 47 specifies Windows uses the NtQueryInformationFile ... NtSetInformationFile ... The definition of the function used to process any file information request, including its content and the function signature, is implementation-dependent and is not part of the protocol specification. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Wednesday, November 25, 2009 8:30 AM To: 'Tim Prouty' Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: RE: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Good morning Tim. Bill Wesse from the Documentation Support team here. I will be your contact for this issue. We have created the following case to track our investigation: SRX091124600335 [MS-SMB] Trans2SetPathInfo() not enforcing share mode I will begin work this morning, and will update you with status before the end of the day. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Tuesday, November 24, 2009 6:07 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi, Based on the ZwSetInformationFile() docs (http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file. The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? I have attached a pcap of a client executing these exact steps against a win7 server. Packet 27/28: Step 1 Packet 29/30: Step 2 Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced. Thanks! -Tim
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
On Wed, Nov 25, 2009 at 05:14:26PM +, Bill Wesse wrote: Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. That won't wash I'm afraid. If it's visible on the wire, and it changes the visible behaviour of the file server, then it needs to get documented. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Jeremy, I agree with you concerning Windows behavior needing to be documented; but I felt it necessary to mention the possibilities concerning further elaboration - since I am not the one to make that decision (nor do I wish to second guess those who do). My next step is to finish tracking down file handle visibility within the server, and how that applies to pass-through versus no pass-through: as you noted, there are certainly differences, the main one concerning why pass-through doesn't honor the share mode. My first take on this is to assume pass-through obtains the existing handle (making it safe to set the size); but I have not yet confirmed this (or proven it wrong - in which case I would be intensely bothered by the behavior, which would have the implication of corrupting the state of file state under the original handle). Either way, I do intend to file a TDI on the topic, once I finish the code study; I also intend to set up test code to exercise the information levels against the SMB calls. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Jeremy Allison [mailto:j...@samba.org] Sent: Wednesday, November 25, 2009 1:46 PM To: Bill Wesse Cc: Tim Prouty; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes On Wed, Nov 25, 2009 at 05:14:26PM +, Bill Wesse wrote: Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. That won't wash I'm afraid. If it's visible on the wire, and it changes the visible behaviour of the file server, then it needs to get documented. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Question: Which existing handle would the pass-through be using? The handle opened in packet #28 is a separate tcp connection and a separte session from the Trans2SetPathInfo in packet #33. I'm not aware of any situation where the server is expected to share file handles across multiple sessions. Is this an exception? Response: I was paying more attention to the PID (0x26CD) - and didn't drill down closer to the sessions (both of which use the same security principal). Thanks for pointing that out; I will take it into account during my ongoing study (this implies a straight share mode bypass). Question: If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Response: That is certainly one of my goals - as I noted in my recent response to Jeremy, I intend to set up test code to exercise the information levels against the SMB calls. As I also mentioned, I will submit a TDI against this - before starting on any test code. Also, the best reference for the full roster of info levels is at: MSDN WDF_FILE_INFORMATION_CLASS http://msdn.microsoft.com/en-us/library/dd568296.aspx this being a subset: [MS-FSCC] 2.4 File Information Classes http://msdn.microsoft.com/en-us/library/cc232064.aspx Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Wednesday, November 25, 2009 1:21 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi Bill, Thank you for the quick answer! I have a few comments/questions below. On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote: Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. Which existing handle would the pass-through be using? The handle opened in packet #28 is a separate tcp connection and a separte session from the Trans2SetPathInfo in packet #33. I'm not aware of any situation where the server is expected to share file handles across multiple sessions. Is this an exception? I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through value), since that requires the file handle (per [MS- CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx) . I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the same session would have succeeded. -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Hi, Based on the ZwSetInformationFile() docs (http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file. The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? I have attached a pcap of a client executing these exact steps against a win7 server. Packet 27/28: Step 1 Packet 29/30: Step 2 Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced. Thanks! -Tim trans2setpathinfo_against_win7.pcap Description: Binary data ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Hi Tim, Thanks for your ZwSetInformationFile() question. One of our team will contact you shortly. Tom Jebo Microsoft Open Specifications Documentation Support -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Tuesday, November 24, 2009 6:07 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi, Based on the ZwSetInformationFile() docs (http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file. The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? I have attached a pcap of a client executing these exact steps against a win7 server. Packet 27/28: Step 1 Packet 29/30: Step 2 Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced. Thanks! -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Thanks Tom. The question is really about SMB1 Trans2SetPathInfo(). I was just referencing ZwSetInformationFile() for some background on the issue. -Tim On Nov 24, 2009, at 3:35 PM, Tom Jebo wrote: Hi Tim, Thanks for your ZwSetInformationFile() question. One of our team will contact you shortly. Tom Jebo Microsoft Open Specifications Documentation Support -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Tuesday, November 24, 2009 6:07 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi, Based on the ZwSetInformationFile() docs (http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file. The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? I have attached a pcap of a client executing these exact steps against a win7 server. Packet 27/28: Step 1 Packet 29/30: Step 2 Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced. Thanks! -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
