Hi Norbert,
I was able to reproduce the same behavior as you describe. We will get
this fixed to behave as expected - always direct the CREATE to the
device object specified. It’s too late to fix this in XP SP2, but I
think we should be able to get this fixed in Server 2003 SP1.
For now, to ensure you get the directed open behavior you desire, please
always open via the full path. Since the large majority of CREATEs you
see will be with the full path, I don’t think the extra overhead you
will introduce by using full path opens on the IOs which use related
opens should cause a performance problem.
As a side note, your open using IoCreateFileSpecifyDeviceObjectHint
would get redirected as expected if one of the following were true:
* the related file object represents a direct device open (instead of a
directory)
* the related file object is not a direct device open, was also opened
with IoCreateFileSpecifyDeviceObjectHint and directed to the same device
object.
As the code is currently written, the CREATE will be directed to the
device object specified by the related file object if the related file
object is not a direct device open (this is the bug that needs to be
fixed).
Thank you for reporting this issue.
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 Norbert Gruber
Sent: Monday, July 19, 2004 2:07 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Question to IoCreateFileSpecifyDeviceObjectHint
Hi Molly,
I verified again that the DeviceObject Parameter is not NULL.
I also call now ObOpenObjectByPointer to get the handle for the
related FileObject instead of ObFindHandleForObject.
status = ObOpenObjectByPointer(FileObject->RelatedFileObject,
OBJ_KERNEL_HANDLE, NULL, 0, 0,
KernelMode, &hRelatedFileObject);
The result is the same, the Create is sent to the top of the stack!
I tried now to use the full path name also in the case that there is a
related fileobject. In this case the Create is sent correctly to the
next device in the stack.
So the problem is definitly only there if I try a relative open! You
cannot reproduce this problem, can you?
I am thinking now about to use always an absolute open. Do you think
this would be a problem? (performance etc.).
Thanks,
Norbert
-----Original Message-----
That is curious – it should only send the CREATE through the top of
the
stack if the DeviceObject parameter passed in is NULL. As a sanity
check, can you verify that you didn’t pass in a NULL as the device
object parameter?
As a side note, you should use ObOpenObjectByPointer to get a HANDLE
to
the FileObject that you already have.
I definitely don’t expect the behavior you are describing. Let me do
some investigation and I’ll get back to you.
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 Norbert Gruber
Sent: Friday, July 16, 2004 12:09 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Question to IoCreateFileSpecifyDeviceObjectHint
Hi Molly,
Thanks for your response.
I don’t get an error when I make a relative open with
IoCreateFileSpecifyDeviceObjectHint! The only problems seems to be
that it enters the stack at the top. This does not happen when I make
an absolute open (e.g. with “type c:\lctest\test1.txt”)!
In this callstack you can see what happens when I make an relative
open (e.g. with “type test1.txt”): (LCFILT and LCENC are our drivers)
81ad3020 81954d30 818458d0 lcencm!PreTrackCreateWorkHorse+0x191
81ad3020 81954d30 81954ec0 lcencm!PreTrackCreate+0x846
817355a0 81954d30 81954ec0 lcfiltm!FilterCreateDispatch+0x19f
817355a0 81954d30 81954ee4 lcencm!SuperCreate+0x9c
81954d40 81ae3c08 81838ad0 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may
be wrong
00804801 81954d30 804eca36 FILEM+0x6d25
818048b8 00000000 8174dba0 FILEM+0x6e79
817fe0e0 00000000 8174dba0 nt!IopParseFile+0x44
00000044 f7ee2274 00000240 nt!ObpLookupObjectName+0x117
00000000 00000000 f7ee2300 nt!ObOpenObjectByName+0xe9
f7ee2720 00100081 f7ee23b0 nt!IopCreateFile+0x407
f7ee2720 00100081 f7ee23b0 nt!IoCreateFileSpecifyDeviceObjectHint+0x4c
81ad3020 817f6670 00000080 lcencm!CustomCreateIrpXP+0x2d3
81ad3020 817f6670 818458d0 lcencm!PreTrackCreateWorkHorse+0x16bc
81ad3020 817f6670 817f6800 lcencm!PreTrackCreate+0x846
817355a0 817f6670 817f6800 lcfiltm!FilterCreateDispatch+0x19f
817355a0 817f6670 817f6824 lcencm!SuperCreate+0x9c
817f6680 81ae3c08 f7ee2c20 nt!IopfCallDriver+0x31
00804801 817f6670 804eca36 FILEM+0x6d25
818048b8 00000000 81773d98 FILEM+0x6e79
817fe0e0 00000000 81773d98 nt!IopParseFile+0x44
00000044 f7ee2bc0 00000040 nt!ObpLookupObjectName+0x117
00000000 00000000 00000001 nt!ObOpenObjectByName+0xe9
0012f778 0012f750 00000000 nt!NtQueryAttributesFile+0xe9
0012f778 0012f750 00000000 nt!KiSystemService+0xc4
Here is the code how we call IoCreateFileSpecifyDeviceObjectHint.
//
// If this is a relative open, then we have to convert the
// RelatedFileObject pointer to a file handle! For this we use the
// (undocumented!) function ObFindHandleForObject
//
if (FileObject->RelatedFileObject)
{
ObFindHandleForObject(PsGetCurrentProcess(),
FileObject->RelatedFileObject, 0, NULL,
&hRelatedFileObject);
if (!hRelatedFileObject)
{
fUseOldCustomCreateIrp = TRUE;
}
}
//
// We can only continue if we have found a handle to the related file
// object
//
if (!fUseOldCustomCreateIrp)
{
//
// For calling IoCreateFileSpecifyDeviceObjectHint we need the name of
// the file to be opened
//
if (hRelatedFileObject)
{
//
// This is a relative open -> just use the file name from the
// file object
//
uniFileName.MaximumLength =
(USHORT)(FileObject->FileName.MaximumLength);
uniFileName.Buffer =
(PUSHORT)ExAllocatePoolWithTag(NonPagedPoolCacheAligned,
uniFileName.MaximumLength, ‘7HpE’);
uniFileName.Length = (USHORT)(FileObject->FileName.Length);
RtlCopyUnicodeString(&uniFileName, &FileObject->FileName);
}
else
{
//
// This is an absolute open -> we need a fully qualified path ->
// add the drive letter
//
uniFileName.MaximumLength =
(USHORT)(FileObject->FileName.MaximumLength + 100);
uniFileName.Buffer =
(PUSHORT)ExAllocatePoolWithTag(NonPagedPoolCacheAligned,
uniFileName.MaximumLength, ‘8HpE’);
uniFileName.Length = 0;
wcscpy(uniFileName.Buffer, L"\??\X:");
uniFileName.Buffer[4] = deviceInfo->DriveLetter;
uniFileName.Length =
(USHORT)(wcslen(uniFileName.Buffer)*sizeof(WCHAR));
RtlAppendUnicodeStringToString(&uniFileName,
&FileObject->FileName);
}
//
// Initialize the object attribute structure for the open request
//
InitializeObjectAttributes(&tmpAttributes, &uniFileName,
OBJ_KERNEL_HANDLE|OBJ_CASE_INSENSITIVE, hRelatedFileObject, NULL);
//
// Finally, let the operating system open the file
//
status = s_pIoCreateFileSpecifyDeviceObjectHint(
pHandle,
accessMask,
&tmpAttributes,
&ioStatus,
NULL,
FileAttributes,
ShareAccess,
CreateDisposition,
CreateOptions,
NULL,
0,
CreateFileTypeNone,
NULL,
Options,
DeviceObject);
The DeviceObject is the DeviceObject from the NTFS or FAT volume.
Again, the IoCreateFileSpecifyDeviceObjectHint does not fail, it opens
the file correctly but the problem is that it enters the stack at the
top (we have a detection of this but I would prefer that I don’t see
such creates).
Any idea what we are doing wrong?
Thanks,
Norbert
-----Original Message-----
IoCreateFileSpecifyDeviceObjectHint should work fine for relative
opens.
Have you verified that your relative open using the same parameters
works with IoCreateFile or ZwCreateFile? Also, what error is being
returned?
The bug related to IoCreateFileSpecifyDeviceObjectHint not working
correctly on network file system devices was fixed in Windows XP,
Service Pack 1 and is fixed in Server 2003.
Regards,
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 Norbert Gruber
Sent: Thursday, July 15, 2004 7:54 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Question to IoCreateFileSpecifyDeviceObjectHint
Hi,
I have a problem / question to IoCreateFileSpecifyDeviceObjectHint.
The functions seems to work fine if a have a fully qualified pathname
(I don’t get a Create Irp for that call). But when I specify a
relative pathname and a RootDir handle, the functions enters the stack
at the top (I get an create Irp in this case) and not at the
DeviceObject I specify. Is this a general problem, or do I something
wrong?
(I get the handle to the RootDir by calling ObFindHandleForObject with
the RelatedFileObject from the FileObject in the Create Irp).
Another question:
Is there any solution for Q322726 (IoCreateFileSpecifyDeviceObjectHint
returns INVALID_PARAMTER when called for network file system devices,
if the related file object is NULL)
Thanks,
Norbert
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