Accessing file info during SET_INFO

NTFSD
1

Once a file has been successfully been opened, i.e. IRP_MJ_CREATE has completed, subsequent file IO can commence.

So, suppose an IRP_MJ_SET_INFORMATION then occurs. In the pre-op what is the recommended method for retrieving info on that file (e.g. Check file attributes, Determine if the file has a reparse point)?

Also, in the post-op the changes IRP_MJ_SET_INFORMATION is requesting has already been applied to the file, correct?

2

I’d say you need the easiest way would be to query file attributes. However, it is possible that the attributes are change by the time you get the response from the file system (unless you prevent that).

Yes, in postOp the changes are applied if the operation was successful. If the status is not a success status then the changes will not have been applied.

Thanks,
Alex.

3

What mechanisms are there to ensure the order of these operations?

4

I don’t know of any built-in mechanisms. If you want to order them you’d probably have to implement that yourself.

Alternatively, you could open the file exclusively and so you could eliminate the chance that someone changes the file attributes while you’re looking at it. However, whether this is feasible depends on your application and what it does, and since you haven’t told us anything about it I don’t know if this would work for you or not.

Thanks,
Alex.

5

I suppose one addition to Alex’s comments about the changes being
applied at the time of post-op would be for delete. While the delete has
been applied to the ndoe, the file is not really deleted until the last
file handle is closed. Alternatively, the file could be ‘undeleted’
after it has been marked for deletion. I have seen this technique when
applications want to lock a file since no further opens are allowed
after the delete processing is applied.

Pete

On 10/16/2012 11:02 AM, xxxxx@gmail.com wrote:

I’d say you need the easiest way would be to query file attributes. However, it is possible that the attributes are change by the time you get the response from the file system (unless you prevent that).

Yes, in postOp the changes are applied if the operation was successful. If the status is not a success status then the changes will not have been applied.

Thanks,
Alex.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

6

That makes sense, thanks guys.

Alex, you mentioned to just query the attributes. Do you mean via FltGetInformationFile() or GetFileAttributes() or some other variant?

7

I was thinking of FltQueryInformationFile(), since you’re in a filter and as far as I can tell you didn’t open the file yourself so you need to make sure to not break layering.

Thanks,
Alex.

8

Yes, I did not open the file. Basically the scenario is, when the client changes a file’s read-only flag to off, I want to update the file’s reparse data so on subsequent IRP_CREATE I can log certain usage info.

So FltGetInformationFile() and FltFsIoControl() should do the trick. I’ll have to looking into how big of an issue exclusive file access with be, but I doubt there are many clients simultaneously trying to edit the file attributes as the file attributes are changed via Perforce when a file is marked for edit.

Thanks again, helpful as ever!