Post create callback success operation

NTFSD
1

Hello folks.

Is there set of known (and only) NTSTATUS codes indicating that in post create callback (refering to fltCallbackData->IoStatus.Status) file has been successfully opened?
For sure it will be STATUS_SUCCESS, but what others?
Sure we can use NT_SUCCESS to check it but then what with STATUS_REPARSE - this is rather not correct indicator of really opened file right (here example: Windows-driver-samples/filesys/miniFilter/avscan/filter/avscan.c at main · microsoft/Windows-driver-samples · GitHub)?

Thank you for help.

2

I am not aware of any other NT_SUCCESS statuses apart for STATUS_SUCCESS that indicate that the file has been successfully opened.

There is a huge body of code out there dating back nearly 30 years that makes that assumption

3

Hi Rod,

Well that is pity there is no such clear document about it and actually this sample I posted confuses me more as it made me wonder. It make sense ofc that STATUS_REPARSE it excluded, but then question is why they did not compared to STATUS_SUCCESS, but used NT_SUCCESS - it somehow suggest there are more success statuses that result in having file opened - isn't it?

Looking at this: [MS-ERREF]: NTSTATUS Values | Microsoft Learn

I have few candidates, but not sure all of those can get back from opening file:

  • STATUS_FILE_LOCKED_WITH_ONLY_READERS - probably not for open?
  • STATUS_FILE_LOCKED_WITH_WRITERS - same as above?
  • STATUS_OBJECT_NAME_EXISTS
  • STATUS_CHECKING_FILE_SYSTEM ?
  • STATUS_OPLOCK_BREAK_IN_PROGRESS

hard to say

Thank you

4

You are of course correct. What can I say - not enough coffee when I wrote that.

You are doublt correct in that this area does need clear documentation.

OPLOCK_BREAK_IN_PROGRESS is definitely a possibility (and is documented)

STATUS_REPARSE does mean "the file object isn't open". I would also urge caution over STATUS_PENDING. In theory that doesn't happen with filter manager but never say never.

5

Thank you for answer again,
Well so here is philosophical question: to use NT_SUCCESS() (with exclusions to mentioned) for this purpose or not to use - that is the question :)?

I guess both are ok unless bug pop up due to it.

6

I'd be interested in what other people's 'best practice' is.

I tend to pull out STATUS_REPARSE for special handling (or none), then pull out !NT_SUCCESS().

1 Like
7

I'd be interested in what other people's 'best practice' is.
I'm curious it too.

I tend to pull out STATUS_REPARSE for special handling (or none), then pull out !NT_SUCCESS() .

ok so your typical practice is: if (!NT_SUCCESS(status) || status == STATUS_REPARSE) return; //skip

ofc make sense. Maybe other folks will share some thought on it :slight_smile:

8

Yes, I usually do the !NT_SUCCESS and then special case STATUS_REPARSE (if necessary).

STATUS_OPLOCK_BREAK_IN_PROGRESS means the open was successful but the data is not yet coherent on the server. You'll only see if you're on the server and it only needs special consideration if you're planning on using the resulting File Object for I/O (e.g. FltReadFile).