STATUS_REPARSE misunderstanding

Hello guys … I want to understand something and correct me if I’m wrong because I feel that I’m missing something: what I understand is that when a process call CreateFileA for some well defined reparse point ((junction / symbolic link etc) example : C:\Path\To\Junction which will trigger a I/O request of type IRP_MJ_CREATE … this request will be processed by all active pre callback of existing mini filters and at the end it will reach the storage stack and then back to the ntfs.sys that will find out that it’s a reparse point so it will set the STATUS_REPARSE in the I/O request and then leave it to the active post call backs… I’m correct ? because I’m debugging a driver that use a well defined reparse point that is recognized normally by ntfs.sys and it looks like ntfs.sys doesn’t set the flag STATUS_REPARSE before transferring the I/O request to the post call backs … why?

Win10+ supports a reparse ECP you can set in PreCreate that lets you optimize out the STATUS_REPARSE return. NTFS will instead complete the request successfully with the OPEN_REPARSE_POINT_TAG_ENCOUNTERED bit set in the ECP. This isn’t used for symlinks/junctions but minifilters use it for their own reparse points:

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/fltkernel/nf-fltkernel-fltaddopenreparseentry

Not sure if that’s what’s happening but worth looking into.

I will check this possibility too, thanks for the suggestion I will back to you soon with the results… that looks interesting ^^