Might it be a small improvement of this function?
About the code retreiving the name of a relative opened file, it’ll first
invoke the function SpyQueryFileSystemForFileName on the parent file object
to retrieve the name of the parent directory, can we simply invoke the
SpyQueryFileSystemForFileName on the current fileobject since it’ll save a
lot of lines, I wonder if it will bring bugs if I do so, but seems it works
fine till now.
The relative code are listed below, would it be better to change the
FileObject->RelatedFileObject to FileObject in the call of
SpyQueryFileSystemForFileName?
//
// CASE 3: We are opening a file that has a RelatedFileObject.
//
else if (FlagOn( LookupFlags, NLFL_IN_CREATE ) &&
(NULL != FileObject->RelatedFileObject)) {
//
// Must be a relative open. Use ObQueryNameString to get
// the name of the related FileObject. Then we will append this
// fileObject’s name.
//
// Note:
// The name in FileObject and FileObject->RelatedFileObject are
accessible. Names further up
// the related file object chain (ie
FileObject->RelatedFileObject->RelatedFileObject)
// may not be accessible. This is the reason we use
ObQueryNameString
// to get the name for the RelatedFileObject.
//
PFILE_NAME_INFORMATION relativeNameInfo =
(PFILE_NAME_INFORMATION)buffer;
ULONG returnLength;
status = SpyQueryFileSystemForFileName(
FileObject->RelatedFileObject,
devExt->AttachedToDeviceObject,
sizeof( buffer ),
relativeNameInfo,
&returnLength );
if (NT_SUCCESS( status ) &&
((FileName->Length + relativeNameInfo->FileNameLength +
FileObject->FileName.Length + sizeof( L’\’ ))
<= FileName->MaximumLength)) {
//
// We were able to get the relative fileobject’s name and we
have
// enough room in the FileName buffer, so build up the file
name
// in the following format:
// [volumeName][relativeFileObjectName][FileObjectName]
// The VolumeName is already in FileName if we’ve got one.
//
RtlCopyMemory(
&FileName->Buffer[FileName->Length/sizeof(WCHAR)],
relativeNameInfo->FileName,
relativeNameInfo->FileNameLength );
FileName->Length += (USHORT)relativeNameInfo->FileNameLength;
} else if ((FileName->Length + FileObject->FileName.Length +
sizeof(L"…\")) <=
FileName->MaximumLength ) {
//
// Either the query for the relative fileObject name was
unsuccessful,
// or we don’t have enough room for the relativeFileObject
name, but we
// do have enough room for “…[fileObjectName]” in FileName.
//
status = RtlAppendUnicodeToString( FileName, L"…\" );
ASSERT( status == STATUS_SUCCESS );
}
//
// If there is not a slash and the end of the related file object
// string and there is not a slash at the front of the file object
// string, then add one.
//
if (((FileName->Length < sizeof(WCHAR) ||
(FileName->Buffer[(FileName->Length/sizeof(WCHAR))-1] !=
L’\‘))) &&
((FileObject->FileName.Length < sizeof(WCHAR)) ||
(FileObject->FileName.Buffer[0] != L’\')))
{
RtlAppendUnicodeToString( FileName, L"\" );
}
//
// At this time, copy over the FileObject->FileName to the FileName
// unicode string.
//
RtlAppendUnicodeStringToString( FileName, &FileObject->FileName );
}
“Molly Brown” wrote in message
news:xxxxx@ntfsd…
This bit of logic is due to the fact that network file systems structure
their device objects differently than local file systems.
For local file systems, the file system has one device object, which we
call its control device object, on which it gets general control type
requests (like, mount or shutdown) then it has a separate device object,
which we call a volume device object, for each volume it has mounted
(e.g., c:, d:, etc.). Therefore, IOs to different volumes go to
different device objects.