Carp, you’re a damn fine man. Don’t listen to whoever told you that.
mm
On Apr 9, 2015 12:06 PM, “Alex Carp” wrote:
> 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
>>
>
> — 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