All,
I’m developing a minifilter that reports file activity on certain files.
There is a user mode service that specifies the pathnames of the files of
interest. The pathnames are specified using the DOS name. At post create
time, the driver is filtering on the pathname to determine whether this is a
file of interest or not. To convert the non-persistent volume name to the
DOS name, the driver is call IoVolumeDeviceToDosName(). This seems to work
ok unless there is a volume mounted as a reparse point. In this case,
IoVolumeDeviceToDosName() hangs with a deadlock.
I tried ignoring all create operations that specify FILE_OPEN_REPARSE_POINT
as an option but found that delete/rename operations also use this option -
which I thought was weird. (The filter needs to detect these operations).
Questions:
- Does anyone know why IoVolumeDeviceToDosName() would hang on a reparse
point?
- Is there a reliable what to distinquish reparse points for remounted
volumes?
- Is there a user mode API that can get returns the non-persistent name of
a volume? Does FilterVolumeFindFirst or FilterVolumeInstanceFindFirst do
this?
TIA!
BTW: The filter needs to work on XP and above.
“JJames” wrote in message news:xxxxx@ntfsd…
> All,
> I’m developing a minifilter that reports file activity on certain files.
> There is a user mode service that specifies the pathnames of the files of
> interest. The pathnames are specified using the DOS name. At post create
> time, the driver is filtering on the pathname to determine whether this is
> a file of interest or not. To convert the non-persistent volume name to
> the DOS name, the driver is call IoVolumeDeviceToDosName(). This seems to
> work ok unless there is a volume mounted as a reparse point. In this case,
> IoVolumeDeviceToDosName() hangs with a deadlock.
>
> I tried ignoring all create operations that specify
> FILE_OPEN_REPARSE_POINT as an option but found that delete/rename
> operations also use this option - which I thought was weird. (The filter
> needs to detect these operations).
>
> Questions:
> 1. Does anyone know why IoVolumeDeviceToDosName() would hang on a reparse
> point?
> 2. Is there a reliable what to distinquish reparse points for remounted
> volumes?
> 3. Is there a user mode API that can get returns the non-persistent name
> of a volume? Does FilterVolumeFindFirst or FilterVolumeInstanceFindFirst
> do this?
>
> TIA!
>
>
>
>
This is only on XP, right?
And WHICH name do you try to convert? The passed in file name (i.e. FltMgr provided name), or the user-land
provided one?
Don’t you keep a table of volume contexts <-> DOS name associations instead od querying in post-create? (maybe
you do, it just sounds to me you don’t).
I did notice an issue with reparse points on XP, and resorted to querying the DOS name in first open on that
volume instead of in the InstanceSetupCallback - I did not encounter any deadlocks on mount points (and customers
use a LOT of them).
JJames wrote:
All,
I’m developing a minifilter that reports file activity on certain files.
There is a user mode service that specifies the pathnames of the files of
interest. The pathnames are specified using the DOS name. At post create
time, the driver is filtering on the pathname to determine whether this is a
file of interest or not. To convert the non-persistent volume name to the
DOS name, the driver is call IoVolumeDeviceToDosName(). This seems to work
ok unless there is a volume mounted as a reparse point. In this case,
IoVolumeDeviceToDosName() hangs with a deadlock.
I tried ignoring all create operations that specify FILE_OPEN_REPARSE_POINT
as an option but found that delete/rename operations also use this option -
which I thought was weird. (The filter needs to detect these operations).
Questions:
- Does anyone know why IoVolumeDeviceToDosName() would hang on a reparse
point?
- Is there a reliable what to distinquish reparse points for remounted
volumes?
- Is there a user mode API that can get returns the non-persistent name of
a volume? Does FilterVolumeFindFirst or FilterVolumeInstanceFindFirst do
this?
TIA!
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
I always have the service convert the WIN32 path to the NT path. The driver
only sees the NT path.
For mounts, I have the driver report the mount by sending the volume GUID.
The service converts the GUID to the WIN32 path with the GetVolumePathNames
WIN32 call.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of JJames
Sent: Tuesday, December 28, 2010 12:09 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Calling IoVolumeDeviceToDosName for Reparse Points
All,
I’m developing a minifilter that reports file activity on certain files.
There is a user mode service that specifies the pathnames of the files of
interest. The pathnames are specified using the DOS name. At post create
time, the driver is filtering on the pathname to determine whether this is a
file of interest or not. To convert the non-persistent volume name to the
DOS name, the driver is call IoVolumeDeviceToDosName(). This seems to work
ok unless there is a volume mounted as a reparse point. In this case,
IoVolumeDeviceToDosName() hangs with a deadlock.
I tried ignoring all create operations that specify FILE_OPEN_REPARSE_POINT
as an option but found that delete/rename operations also use this option -
which I thought was weird. (The filter needs to detect these operations).
Questions:
- Does anyone know why IoVolumeDeviceToDosName() would hang on a reparse
point?
- Is there a reliable what to distinquish reparse points for remounted
volumes?
- Is there a user mode API that can get returns the non-persistent name of
a volume? Does FilterVolumeFindFirst or FilterVolumeInstanceFindFirst do
this?
TIA!
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars (including our new fs
mini-filter seminar) 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
Thanks Dejan.
The driver needs to work on XP and above. The name I’m trying to convert is
the non-persistent name returned by FltGetFileNameInformation() and this
function is being call at post create time.
The driver is not keeping track of the dos names. Getting the DOS name is
the problem I’m trying to solve. It seems that whenever a driver call
IoVolumeDeviceToDosName() it risks a deadlock. IoVolumeDeviceToDosName can
deadlock on InstanceSetup on XP and apparently it can deadlock on reparse
points at PostCreate as well. So how are you getting the DOS name of a
volume? Your message said something about getting it on the first open of
the volume so I assume you mean at post-create time - is this correct?
Thanks.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> This is only on XP, right?
> And WHICH name do you try to convert? The passed in file name (i.e.
> FltMgr provided name), or the user-land
> provided one?
> Don’t you keep a table of volume contexts <-> DOS name associations
> instead od querying in post-create? (maybe
> you do, it just sounds to me you don’t).
>
> I did notice an issue with reparse points on XP, and resorted to
> querying the DOS name in first open on that
> volume instead of in the InstanceSetupCallback - I did not encounter any
> deadlocks on mount points (and customers
> use a LOT of them).
>
> JJames wrote:
>
>> All,
>> I’m developing a minifilter that reports file activity on certain files.
>> There is a user mode service that specifies the pathnames of the files of
>> interest. The pathnames are specified using the DOS name. At post create
>> time, the driver is filtering on the pathname to determine whether this
>> is a
>> file of interest or not. To convert the non-persistent volume name to the
>> DOS name, the driver is call IoVolumeDeviceToDosName(). This seems to
>> work
>> ok unless there is a volume mounted as a reparse point. In this case,
>> IoVolumeDeviceToDosName() hangs with a deadlock.
>>
>> I tried ignoring all create operations that specify
>> FILE_OPEN_REPARSE_POINT
>> as an option but found that delete/rename operations also use this
>> option -
>> which I thought was weird. (The filter needs to detect these operations).
>>
>> Questions:
>> 1. Does anyone know why IoVolumeDeviceToDosName() would hang on a reparse
>> point?
>> 2. Is there a reliable what to distinquish reparse points for remounted
>> volumes?
>> 3. Is there a user mode API that can get returns the non-persistent name
>> of
>> a volume? Does FilterVolumeFindFirst or FilterVolumeInstanceFindFirst do
>> this?
>>
>> TIA!
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) 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
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
I get the DOS name of the volume at pre-create time. However I store it in the volume context! So I don’t query
it every time. You should do the same.
This way you don’t need to query the DOS name on every post-create, instead you call FGFNI, use the volume
context for the DOS letter version of the volume and the FGFNI returned data for the rest.
Dejan.
JJames wrote:
Thanks Dejan.
The driver needs to work on XP and above. The name I’m trying to convert is
the non-persistent name returned by FltGetFileNameInformation() and this
function is being call at post create time.
The driver is not keeping track of the dos names. Getting the DOS name is
the problem I’m trying to solve. It seems that whenever a driver call
IoVolumeDeviceToDosName() it risks a deadlock. IoVolumeDeviceToDosName can
deadlock on InstanceSetup on XP and apparently it can deadlock on reparse
points at PostCreate as well. So how are you getting the DOS name of a
volume? Your message said something about getting it on the first open of
the volume so I assume you mean at post-create time - is this correct?
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
@OSR_Community_User can you please show some code how you have done it. I am struggling to do the same. I am new to driver programming. Thanks a lot.
@jay96612 … you’re answering a ten year old post attributed to a generic placeholder username.
If you have a question, start a new thread.
Thread closed.
Peter