Using FileObject->FileName in filter driverIf you enumerate the tree with
splay, the list will be flattened. You can enumerate the list without
playing and it will not effect the balance.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Thursday, May 10, 2001 8:26 AM
To: File Systems Developers
Subject: [ntfsd] RE: Using FileObject->FileName in filter driver
Nevermind… It IS documented:
If a matching element is found, RtlLookupElementGenericTable rebalances
the generic table’s splay tree.
-----Original Message-----
From: Smith, Joel
Sent: Thursday, May 10, 2001 11:12 AM
To: ‘File Systems Developers’
Subject: RE: [ntfsd] RE: Using FileObject->FileName in filter driver
Speaking of the generic table package, someone once told me that this
splay tree implementation at times rebalances during read operations, which
seemed strange to me (but having never actually implemented a splay tree, I
took this persons word for it). Later, a different person (rather
emphatically) indicated that this notion was incorrect. Could someone clear
this up for me? If true, it would have some serious implications on how
access to the tables is synchronized and should be documented.
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, May 10, 2001 11:04 AM
To: File Systems Developers
Subject: [ntfsd] RE: Using FileObject->FileName in filter driver
Try the RtlGenericTable package defined in NTIFS.H. It uses a splay
tree and has performaed great in all of my filter drivers.
jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Chtchetkine, Vladimir
Sent: Wednesday, May 09, 2001 3:05 PM
To: File Systems Developers
Subject: [ntfsd] RE: Using FileObject->FileName in filter driver
Well guys, you have very strong arguments!
And definitely, this
is not something for which I would sacrifice reliability of my product. But
(to me) it worth a try.
And sorry if I took too much of your time on this topic.
Just as a follow-up. What would be the best algorithm for hashing
FOs (generating the keys)? With reasonable table size and good level of the
key uniqueness?
Best regards,
Vladimir
-----Original Message-----
From: Daniel Lovinger [mailto:xxxxx@exchange.microsoft.com]
Sent: Wednesday, May 09, 2001 1:52 PM
To: File Systems Developers
Subject: [ntfsd] RE: Using FileObject->FileName in filter driver
I think Joel says it better than I could. There are plenty of ways
to get better than linear access times.
I am also definitely not saying there are no problems with your
proposed mechanism. What I’m trying to get across is that this is not your
data: do not touch it. This is how we run into really nasty problems. Just
because the data should not be used after create does not mean it should be
reused by the first component to get to it.
-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, May 09, 2001 1:00 PM
To: File Systems Developers
Subject: [ntfsd] RE: Using FileObject->FileName in filter driver
Forgive me for being dense (I have a feeling I’m missing
something), but aren’t we talking about associating contexts with file
objects? What’s wrong with the tried and true mechanisms of maintaining a
volume relative balanced tree or hash table mapping file objects to whatever
data you need to associate them? I mean, is log (number_of_file_objects) to
near constant time (avg) for lookups really that bad? Unless you have a
large and experienced testing department or Tony Mason-ish brainpower, don’t
try to be too clever (Been there done that!).
-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Wednesday, May 09, 2001 10:33 AM
To: File Systems Developers
Subject: [ntfsd] RE: Using FileObject->FileName in filter driver
Daniel:
Thank you for the reply. So, as I understood, there are no
problems with implementing that mechanism. At least on W2K SP1 - NTFS
FileName is not freed until FileObject gets closed (which is
reasonable approach). And nobody use it because docs say “don’t rely on it”.
What a waste of space! 
I understand all that you’ve said and I’m agreed with you 100%.
I’m simply trying to optimize my driver’s performance and one of the
bottlenecks
that I’ve found is searching for my FileObject’s descriptor in
each and every IRP and Fast I/O request. On heavy loads (like building big
projects: > 10K
files) my table consists of hundreds (if not thousands) of
descriptors and browsing through it can be costly. Of course, if performance
benefit will
be insignificant I’m not going to use that “dirty trick”. I’m
not even sure if I will use it in any case. I just wanted to see some
implications that I
might oversee when I originally thought about that mechanism.
Best regards,
Vladimir
-----Original Message-----
From: Daniel Lovinger [mailto:xxxxx@exchange.microsoft.com]
Sent: Tuesday, May 08, 2001 6:47 PM
To: File Systems Developers
Subject: [ntfsd] RE: Using FileObject->FileName in filter driver
No.
If 1-3 will be required to work, simply use your normal
mechanism. Trying to squeeze into cracks like this will generate problems
not just with drivers which may, erroneously as you observe, sniff the
filename field, but with the OS if we try to make the rule more obvious in
the future by freeing the buffer and/or using the verifier to catch folks
peeking at it, etc.
With regard to 3, you really have no way of guessing when the
OS could decide to free it and I definitely am not going to give you any
guarantee here as to how it would/could work in the future. As a starting
point, one could expect the IO manager to do it (if it ever does) in
IopParseDevice, after the create is complete. This would be after your
completion routine runs.
The basic rule here is that you should never reuse fields of
internal structures, ever, unless they are documented that way.
-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@Starbase.com]
Sent: Tuesday, May 08, 2001 4:36 PM
To: File Systems Developers
Subject: [ntfsd] Using FileObject->FileName in filter driver
Hi everyone.
Can I store my filter’s private data in FileObject->FileName
field after file gets opened (i.e. Create to the underlying FSD has been
completed)?
Since FileName field is no longer “valid” at this point I’d
like to utilize it to store my filter’s private information associated with
this FileObject.
What I’m thinking is (kinda algorithm):
-
Before I pass IRP_MJ_CREATE to the underlying FSD I save
all FileName’s structure fields.
-
After underlying FSD has successfully completed the IRP I
compare current FileName fields with those that I have saved at step 1.
-
If they are equal or FileName has been “zeroed” (i.e.
freed) I think that I can reuse it and deallocate FileName.Buffer (if it has
not been
“zeroed” yet), prepare a UNICODE string that represents my
filter’s private data in string format (including a signature at the
beginning of the string)
and then save this string in FileName.
4. When filtering subsequent requests I check FileName for the
signature and if it matches what I’m expecting I will parse that string and
extract
whatever I have saved during Create.
So, if someone below my filter (another filter or FSD itself)
has changed FileName during IRP_MJ_CREATE I will not touch it (1-3)
If someone has changed FileName afterwards I will detect it by
checking the signature and will use some “conventional” mechanism to get
associated data.
To me these sound reasonable. How about you? 
Any feedback is highly welcome!
Vladimir
You are currently subscribed to ntfsd as:
xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as:
xxxxx@Starbase.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as:
xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as:
xxxxx@Starbase.com
To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com