最新消息:Welcome to the puzzle paradise for programmers! Here, a well-designed puzzle awaits you. From code logic puzzles to algorithmic challenges, each level is closely centered on the programmer's expertise and skills. Whether you're a novice programmer or an experienced tech guru, you'll find your own challenges on this site. In the process of solving puzzles, you can not only exercise your thinking skills, but also deepen your understanding and application of programming knowledge. Come to start this puzzle journey full of wisdom and challenges, with many programmers to compete with each other and show your programming wisdom! Translated with DeepL.com (free version)

windows - Why is FILE_FLAG_BACKUP_SEMANTICS needed to open a directory with CreateFile()? - Stack Overflow

matteradmin6PV0评论

The documentation for CreateFile() specifies that:

To open a directory using CreateFile, specify the FILE_FLAG_BACKUP_SEMANTICS flag as part of dwFlagsAndAttributes.

What I don't understand is why this flag is needed.

The documented meaning of the flag is:

The file is being opened or created for a backup or restore operation. The system ensures that the calling process overrides file security checks when the process has SE_BACKUP_NAME and SE_RESTORE_NAME privileges.

How is this related to directories?

I've been looking for an answer to this for a while now.

The documentation for CreateFile() specifies that:

To open a directory using CreateFile, specify the FILE_FLAG_BACKUP_SEMANTICS flag as part of dwFlagsAndAttributes.

What I don't understand is why this flag is needed.

The documented meaning of the flag is:

The file is being opened or created for a backup or restore operation. The system ensures that the calling process overrides file security checks when the process has SE_BACKUP_NAME and SE_RESTORE_NAME privileges.

How is this related to directories?

I've been looking for an answer to this for a while now.

Share Improve this question edited Nov 18, 2024 at 20:30 Remy Lebeau 602k36 gold badges508 silver badges853 bronze badges asked Nov 18, 2024 at 17:34 KillStealKSKillStealKS 211 bronze badge 2
  • FILE_FLAG_BACKUP_SEMANTICS: You must set this flag to obtain a handle to a directory. – Jeaninez - MSFT Commented Nov 19, 2024 at 2:33
  • Yes, @Jeaninez-MSFT, we know that. It's literally spelled out in the first paragraph of the question. – IInspectable Commented Nov 19, 2024 at 12:24
Add a comment  | 

2 Answers 2

Reset to default 1

Look at the operations you can perform on a directory handle. They're all backup-related. This isn't Unix, you don't use a directory handle for readdir or openat It's used for BackupRead, BackupWrite, and change notification (which is also something a backup tool wants, to get a consistent snapshot).

For create or open file, in user mode, need use ZwOpenFile or ZwCreateFile. And we not need use FILE_OPEN_FOR_BACKUP_INTENT option here. Can, but not need. When we want create directory we must pass option FILE_DIRECTORY_FILE. If we not create, but open file, when we pass FILE_DIRECTORY_FILE we say to system, that we want open directory only. If file with such name exist, but it not a directory, we got error, STATUS_NOT_A_DIRECTORY. From another side we can pass FILE_NON_DIRECTORY_FILE option, and if file with such name exist, but it was directory, we got error STATUS_FILE_IS_A_DIRECTORY ( converted to win32 error access denied). If we don't care about directory we want open or not, we can not pass this flags. If use CreateFile for create or open file, possible view that this api take another flags as parameters and less parameters, compare to ZwCreateFile. This api convert passed parameters, before call to ZwCreateFile. We can not direct pass FILE_NON_DIRECTORY_FILE or FILE_DIRECTORY_FILE or 0 here. But indirect, when FILE_FLAG_BACKUP_SEMANTICS set, api pass 0 and when not set - pass FILE_NON_DIRECTORY_FILE. Very strange choice for my look, but as is. In any case backup or restore privilege not mandatory for open or create directory and not related to this at all.

Post a comment

comment list (0)

  1. No comments so far