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
