Haha, thanks Martin :). I think it was rather tongue in cheek anyway :).
On Thu, Apr 9, 2015 at 10:16 AM, Martin O’Brien <
xxxxx@gmail.com> wrote:
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
>
> — 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
>