Re: [ntfsd] Logging file id

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