IRP_MJ_CREATE vs. directory vs. FILE_FLAG_BACKUP_SEMANTICS

NTFSD
1

Hello there,

I’m toying with custom (Dokan-based) file system, and there’s a thing I ran into a long time ago already, and again recently: peculiar handling of IRP_MJ_CREATE for directories.

There are cases when IRP_MJ_CREATE arrives for an object which is a directory without any apparent indication the request should process it as directory (such as FILE_DIRECTORY_FILE). When this happens, request processing “adds FILE_FLAG_BACKUP_SEMANTICS flag silently”/“skips the check”. This doesn’t feel correct, and also breaks a test case where “CreateFile” API should fail with ACCESS_DENIED when invoked on a directory path without FILE_FLAG_BACKUP_SEMANTICS. However, simply going the other route (don’t add the flag and yield STATUS_ACCESS_DENIED) results in cases ACCESS_DENIED errors from some APIs/stuff even when not expected, such as “cd ” from a command line.

I didn’t find any info on this topic so far. FastFat source doesn’t seem to do anything about this flag at all, either. So the question is, what is correct handling there? Should the FILE_FLAG_BACKUP_SEMANTICS be required in some specific cases only? Or am I missing a part of the picture?

Thanks,
L.

2

At the file system level, there is no requirement that directory CREATEs have the FILE_FLAG_BACKUP_SEMANTICS flag.

Even from user mode, callers can open directories without the FILE_FLAG_BACKUP_SEMANTICS flag by using NtCreateFile.

So, your feeling is correct - FILE_FLAG_BACKUP_SEMANTICS probably shouldn’t be silently added. I’ve always found it strange that CreateFile overloads this flag in such a strange way.

Of course, I don’t know anything about your custom file system. Does it make later assumptions about FILE_FLAG_BACKUP_SEMANTICS in a directory open?

Thanks,
Alnoor

3

Thanks! Only assumptions code makes down the road is that the flag should be set for directories, and if not ~ STATUS_ACCESS_DENIED. But that’s an easy toggle.

The only problem it leaves is that CreateFile success even without the FILE_FLAG_BACKUP_SEMANTICS flag set. I can live with that ~ better to fail one case than to yield ACCESS DENIED erroneously in multitude other cases ~ though I sure would like to know how are things happening over there.

Cheers,
L.

4

Are you checking for FILE_NON_DIRECTORY_FILE? If the open is for a directory
and FILE_NON_DIRECTORY_FILE is set then should fail the open with
STATUS_FILE_IS_A_DIRECTORY.

https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys/fastfat/create.c#L1349

-scott
OSR
@OSRDrivers

5

Thanks Scott! That seems to be the issue indeed! FILE_NON_DIRECTORY_FILE was being checked, but not in all relevant code paths. With that addressed things behave correctly :).