Folks,
I am seeing some strange behaviour when I issue ZwQueryInformationFile or ZwSetInformationFile from my “User” space exe on to a file object residing on a CIFS server, accessed using CIFS client.
Here is the description of what I am seeing.
I have an object on a CIFS server (Win2K SP4). I open a handle to it using UNC name (such as \Server\Share\a.txt) passed to ‘CreateFile’ win32 API.
The ‘CreateFile’ API is issue through my ‘User’ space exe running on another Win2K SP4 machine
- ZwQueryInformationFile Problem
On the handle opened using the method above, I issue ZwQueryInformationFile with Information class ‘FileBasicInformaion’.
what i am seeing is that ‘ChangeTime’ member of the FILE_BASIC_INFORMATION structure is set to value
‘-1’ (0xFFFFFFFFFFFFFFFF).
This does not happen every time I call ZwQueryInformationFile with Information class ‘FileBasicInformaion’. Randomely the function returns -1 in timestamp member fields.
I have also observed that when I issue this function to CIFS client, there is no SMB packet on the network.
So this suggest to me that CIFS client is caching some attribute information and returning it directly from its inmemory data strcutures
without going to the actual CIFS server.
Any Idea if such attribute caching exists in CIFS client (I know data caching existing using OPLOCK support) and even if attribute caching exists, why is CIFS client returns a -1 in FILE_BASIC_INFORMATION once in while (again not always).
Instead of issuing a FileBasicInformation query, if I issue a ‘FileNetworkOpenInformation’ query, the returned ‘FILE_NETWORK_OPEN_INFORMATION’
structure never contains a -1 in the timestamp related member fields.
Also for this type of query, I always see a SMB packet on the network.
- ZwSetInformationFile Problem.
Again I open a handle to a remote object using UNC name and ‘CreateFile’. as mentioned above.
On this handle, I first do a FILE_BASIC_INFORMATION query to get the current attributes.
I modify the ‘FileAttributes’ member of the FILE_BASIC_INFORMATION structure to remove the ‘FILE_ATTRIBUTE_READONLY’ bit.
Basically, I am doing the ‘ZwSetInformationFile’ call to Remove the readonly attribute of the file.
I then call ‘ZwSetInformationFile’ with FILE_BASIC_INFORMATION. The values in the ‘FILE_BASIC_INFORMATION’ are the same as those returned by the earlier call to Query, except the ‘FileAttributes’ member is modified as mentioned above.
This call returns me success. I see a SMB Transact2 SET_FILE_INFORMATION packet on the network, But all the timestamp related members are set to -1 in the packet data and the ‘FileAttributes’ field is set to 0.
None of the members of the ‘FILE_BASIC_INFORMATION’ structure that I passed to ‘ZwSetInformationFile’ were set to either -1 or 0.
The respose SMB packet returns success, but if you go to the CIFS server machine and check the attributes on the actual NTFS partition, the readonly bit is still set.
So looks like, because the values that the CIFS Server/NTFS file system saw were either -1 or 0, the server side code ignored those, but still returned success.
So I am wondering, when the CIFS client sends the SMB Transact2 SET_FILE_INFORMATION packet on the network, why are the member fields set to values different than those
that I passed to the ‘ZwSetInformationFile’?
Any idea whats going on here?
Regards,
Manish
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th