I’m just sayin
mm
On Apr 9, 2015 6:20 PM, “Alex Carp” wrote:
> 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
>>
>
> — 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