UDF returns incorrect file information.

Hi!
While working on the file system filter driver, I have faced confusing features of UDF (OS Windows Vista and later).

Background:
I have usb flash with UDF. I create test file on it. The file has one alternative data stream and hard link.

Using FileTest for testing purpose, I get the following:
NtQueryInformationFile with FileStandardInformation returns NumberOfLinks = 3. (The file has only one hardlink.)
NtQueryInformationFile with FileHardLinkInformation returns returns list of FILE_LINK_ENTRY_INFORMATION structures. The first structure in list is Ok, but other structures contains some garbage. (FileTest utility can crash at this point). Besides, content of the FILE_LINKS_INFORMATION structure may not match FILE_LINK_ENTRY_INFORMATION stuctures (EntriesReturned value may not be equival to FILE_LINK_ENTRY_INFORMATION structures number).

I remove the hardlink and alternative data stream.
NtQueryInformationFile with FileStandardInformation returns NumberOfLinks = 2. (The file has no any hardlinks or ADS).
I create new alternative data stream.
Set the FileDispositionInformation.DeleteFile for the file to TRUE. Handle of the file remains open.
Try to open the ads file using another instance of FileTest. As the result, i get STATUS_DELETE_PENDING.
Set the FileDispositionInformation.DeleteFile for the file to FALSE. The descriptor of the file can still be opened or closed, it has no value.
Try to open the ads file using another instance filetest. As the result, i get STATUS_DELETE_PENDING.

So my question is: is this the normal behavior of the file system? Maybe I did something wrong? For example, the NTFS file system is working correctly and I can get the correct value of the information about the file or open the file stream, even if the file is marked as deleted.

I haven’t tried your specific experiment, but I can share that we’ve had
numerous issues with UDFS over the years. These range from strange
behavioral differences between its implementation and NTFS to straight up
bugs (particularly in name handling/querying). You might want to try this on
the latest version of Windows possible and see if you get different
behavior.

-scott
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Hi!
While working on the file system filter driver, I have faced confusing
features of UDF (OS Windows Vista and later).

Background:
I have usb flash with UDF. I create test file on it. The file has one
alternative data stream and hard link.

Using FileTest for testing purpose, I get the following:
NtQueryInformationFile with FileStandardInformation returns NumberOfLinks
= 3. (The file has only one hardlink.)
NtQueryInformationFile with FileHardLinkInformation returns returns list
of FILE_LINK_ENTRY_INFORMATION structures. The first structure in list is
Ok, but other structures contains some garbage. (FileTest utility can crash
at this point). Besides, content of the FILE_LINKS_INFORMATION structure may
not match FILE_LINK_ENTRY_INFORMATION stuctures (EntriesReturned value may
not be equival to FILE_LINK_ENTRY_INFORMATION structures number).

I remove the hardlink and alternative data stream.
NtQueryInformationFile with FileStandardInformation returns NumberOfLinks
= 2. (The file has no any hardlinks or ADS).
I create new alternative data stream.
Set the FileDispositionInformation.DeleteFile for the file to TRUE.
Handle of the file remains open.
Try to open the ads file using another instance of FileTest. As the
result, i get STATUS_DELETE_PENDING.
Set the FileDispositionInformation.DeleteFile for the file to FALSE. The
descriptor of the file can still be opened or closed, it has no value.
Try to open the ads file using another instance filetest. As the result,
i get STATUS_DELETE_PENDING.

So my question is: is this the normal behavior of the file system? Maybe I
did something wrong? For example, the NTFS file system is working correctly
and I can get the correct value of the information about the file or open
the file stream, even if the file is marked as deleted.

OFFTOPIC

The first structure in list is Ok, but other structures contains some garbage.
(FileTest utility can crash at this point).

I checked this and yes it can, due to NextEntryOffset of n-th structure going past the end of the allocated buffer. I fixed the crash. Obviously this is not gonna help you in your UDF issue, but at least should make your experiments more stable.

The latest version is on www-dot-zezula-dot-net. Should you have more issues with FileTest, please, let me know. Thank you.

Hi! Thanks for your answers.
I repeated the test on windows8.1 and windows2012r2 with latest updates. Nothing changes. It remains only to wait for UDFS updates.

OFFTOPIC
Ladislav, thanks for update. FileTest works fine.