That’s a good point about using just a variable instead of a GUID. Only
thing I think might be worth mentioning is that you shouldn’t expect that
all the values generated end up being used, because you might need to drop
some if there are any context attach races (for example, two racing
operations for the same file might initialize contexts with the ID 37 and
38 (let’s assume they’re sequential) and then one of the two contexts will
win and will be attached so the value for the other one won’t appear
anywhere…). IMO this can actually happen somewhat more frequently for the
scenario where you only do this for files you didn’t see an IRP_MJ_CREATE
for because you’re likely doing this in the context of an IO operation, and
those often do happen in parallel on the same handle.
It’s pretty obvious but I wanted to call it out anyway (it’s been recently
pointed out to me that I’m no longer a good judge of what’s obvious and
what’s not in this space 
).
Thanks,
Alex
On Wed, Apr 8, 2015 at 3:38 PM, Marion Bond wrote:
> IMHO when the location of generation for an identifier is a singleton,
> use a monotonic variable rather than a GUID. There is much less overhead
> in an InterlockedIncrement call than in a GuidGen and the results are
> identical - a unique value within your problem scope
>
> But in general I agree: this design handles the problem of files opened
> before attach as well as eliminating a significant performance cost on
> ordinary IO
>
> Sent from Surface Pro
>
> From: Alex Carp
> Sent: Wednesday, April 08, 2015 3:36 PM
> To: Windows File Systems Devs Interest List
>
> Another approach (which is generally safer in my opinion) is to generate a
> GUID whenever you encounter a file without your context (as in, if you’re a
> Post-Write or something) and then queue a request to a thread (take a
> reference on the FILE_OBJECT and pass it to the thread) to issue a
> FltQueryInformationFile and replace the GUID with the proper FileID. I
> think the key thing here is that since you need this for logging then it
> doesn’t matter that you get the FileID right away (as in, in the context of
> THAT operation -> so no need to issue the FltQueryInformationFile in
> postWrite) and instead what matters is that you eventually associate the
> operation with the right FileID before writing the log to file or however
> you plan to log things…
>
> Thanks,
> Alex.
>
> On Wed, Apr 8, 2015 at 8:04 AM, Rod Widdowson
> wrote:
>
>> > Assuming that you are not looking at paging IO
>>>
>>> Why not? If understood right from documentation it can be used for
>>> paging IO.
>>>
>>
>> I agree. Its just theory and practice and a fair amount of paranoia.
>>
>> I’m always super nervous about straying off the beaten track when I’m
>> down the paging IO path. NTFS might suddenly decide to say
>> STATUS_FILE_LOCKING or some such. And only for a specific version and under
>> certain circumstances. So if you rely on it you’ll probably be fine, but
>> unless you have access to the NTFS (or whatever else) sources you’ll never
>> know. Nor will you be able to diagnose it or make a guess at fixing it.
>>
>> Or it might all be OK.
>>
>> It could me that this is regularly called in normal operation (just like
>> getting the file name is) but if it isn’t then there is a chance that it
>> will have rotted, or will rot.
>>
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> 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
>>
>
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers 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
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>