Recently I hit the following case in our native FSFD attached to NTFS on
Windows 2003-SP1 system.
During pre-create I need to get full file name path for the file/directory
that will go down the device stack. I’m aware of issues related to “get file
name” during create (file ID, Object ID, RelatedFileObject,
RelatedFileObject for ADS open, when ->FileName buffer is valid).
My information base is IFS kit documentation, samples from IFS Kit
(3790.1830) and several threads discussed about RelatedFileObject in this
mailing list.
The case where I hit problem is for “// CASE 3: We are opening a file that
has a RelatedFileObject.”:
If file is not open with File ID or Object ID, then for RelatedFileObject !=
NULL case in pre-IRP_MJ_CREATE do:
- Query FS for RelatedFileObject file name.
- Concatenate name from 1. with what *user* has set in
pFileObject->FileName.
This is basically the same approach as in IFS Kit sample NLGetFullPathName
function.
An example of file names I get for this problematic case is:
I query FS for RelatedFileObject name and I get L"\A\B". In
pFileObject->FileName the name that *user* has put there is
L"\A\B\C\SomeFile.dat".
If I concatenate both strings I get L"\A\B\A\B\C\SomeFile.dat" which does
not exist, but (!) the post-IRP_MJ_CREATE is completed with STATUS_SUCCESS!
File that really exists on my FS is L"\A\B\C\SomeFile.dat". Looks like FS
knows that RelatedFileObject should be ignored for this case.
Now, how can I know this in pre-create too?
I noticed that there is leading L’' in pFileObject->FileName (and it is
relative open?) and that the IRP_MJ_CREATE came in from SRV (LAN share).
Can someone bring more light on this case?
WBR Primoz
p.s. I have full memory dump too.