Actually, you only need to call FltGetTunneledName when you are
requesting normalized names. Tunneling doesn’t affect opened names.
With normalized names, the Filter Manager cannot ensure that the final
component is normalized (i.e., ensure we’ve give you the long name)
until *after* the CREATE or RENAME operation has actually occurred since
tunneling can cause a short name to get changed to a longname. The
purpose of FltGetTunneledName is to give you a way to validate that the
name you retrieved in the pre-operation is actually the fully normalized
name in the post-operation.
Yes, you need to propogate the PFLT_FILE_NAME_INFORMATION from the pre-
to the post-operation and release the PFLT_FILE_NAME_INFORMATION when
you are finished using it in the post-operation.
We will get these issues better documented in the Filter Manager docs.
Thanks,
Molly Brown
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, October 26, 2004 8:18 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetTunneledName confusion
Molly:
Hmm. I was calling FltGetTunneledName in the pre-Create and pre-Rename
callbacks.
As I read it more closely, the documentation does indeed indicate that
FltGetFileNameInformation and FltGetDestinationFileName should be called
in pre-operation callbacks, and FltGetTunneledName should be called in
post-operation. (Odd that it would give me something in pre-operation,
but…)
That means that you must propogate the PFLT_FILE_NAME_INFORMATION from
the
pre- to the post-operation, and not release it until the post-operation,
right?
I changed it to call FltGetFileNameInformation and
FltGetDestinationFileName in pre-operation callbacks, and
FltGetTunneledName in post-operation. Now I never see anything come
back from FltGetTunneledName, which is consistent with your explanation.
I always request normalized names, so does that mean I should never have
to fool with FltGetTunneledName? (Whatever the answer is could be a
good FAQ.)
Thanks,
Ken
P.S. Your explanation is very helpful – I recommend you add bits of it
to the documentation. For example, there’s no mention of the short/long
filename.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Molly Brown
Sent: Tuesday, October 26, 2004 7:05 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetTunneledName confusion
FltGetTunneledName should be called from the post-CREATE or post-RENAME
callback. At that time, it tells you if the name created by the
operation has a *long* name which was tunneled by the file system. This
API is only useful if you are requesting normalized file names when
calling FltGetFileNameInformation or FltGetDestinationFileName in
pre-CREATE or pre-RENAME, respectively.
If something.doc is the long name for this file, I wouldn’t expect you
to see any new names when you call FltGetTunneledName.
If something.doc is the short file name, I would expect
FltGetTunneledName to return you the appropriate long name after the
rename in step 2 is completed.
It doesn’t sound like that is what you are seeing. Could you tell me:
* in which operation callbacks you call FltGetFileNameInformation to get
the name you pass to FltGetTunneledName
* in which operation callbacks you call FltGetTunneledName
Thanks,
Molly Brown
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, October 26, 2004 6:58 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetTunneledName confusion
NTFSD Folk:
Using FltGetTunneledName appears to be very subtle. I’d like to use it
correctly but have to admit to some confusion. (I couldn’t find any
sample drivers that use it.)
A typical scenario that would use FltGetTunneledName is MS Word. You’re
probably aware that Word uses temporary files for much of its activity
(“~WRD5678.tmp” in the example below).
If working on “something.doc”, a typical Save operation would be:
- Rename something.doc to ~WRL1234.tmp
- Rename ~WRD5678.tmp to something.doc
- Delete ~WRL1234.tmp
In step 1, FltGetTunneledName returns “something.doc” for
“~WRL1234.tmp”.
(It doesn’t return anything for any other file in any other step.)
Does this mean that it’s renaming “something.doc” to “something.doc”?
What is the meaning of the results of FltGetTunneledName in this
context?
It looks like a very powerful feature if used correctly, but how to do
that isn’t obvious. (My driver is interested in when “something.doc”
gets modified, moved, renamed, deleted, etc., so this seems pretty
relevant.)
Ken
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com