Hi,
I’m receiving create IRPs with the FO_DIRECT_DEVICE_OPEN bit set in
FileObject->Flags. These creates are sent by applications like
Explorer, and FileObject->FileName is always blank and there is no
related file object, so it seems reasonable that the application is
trying to open the volume itself, and things do indeed appear to work
just fine.
However, running a checked build of the kernel/hal, I get an assertion
– ASSERT(!(FileObject->Flags & FO_DIRECT_DEVICE_OPEN)) is triggered
within IoGetRelatedDeviceObject, which is called somewhere down the
line of the original NtCreate/OpenFile call that the application made
(with my root directory as the filename argument; eg, d:), after my FS
has completed the create IRP. It seems reasonable that
IoGetRelatedDeviceObject should complain if being asked to get the
related device object of an actual device object. So why is
IoGetRelatedDeviceObject being called (by IopParseDevice, called by
ObpLookupObjectName, via ObOpenObjectByName)?
I’d appreciate any information on any special processing I need to do
for FO_DIRECT_DEVICE_OPEN (couldn’t find any in fastfat except an
apparently irrelevant comment, and there’s nothing obvious in the
volume open code). My filesystem driver is not a filter, but it is
layered on NTFS or FAT.
Thanks in advance,
Derrick
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.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