Jonas L

Sweet :) Just to make sure I’m not missing something, this does require SeCreateSymbolicLink, right?

Junction folders with files inside rely on a design flaw in NTFS. When a file gets renamed this happes: Permission check, can we delete it from current dir. Permission check, can we create in destination dir. Yes: Then lock detination dir so its impossible to open with DELETE

If its already opened with DELETE then abort rename move operation. Then the source file, gets "deattached" from source dir, and created in destination dir. But what about junction folders? They only require FILE_WRITE_ATTRIBUTES. So if the reparse point gets applied

when the source file have lefts its source directory the move operation WILL happen regardless of the directory now being a junction folder :) By sending the rename through slow ntobj mgr lookups we get easily a multiply second window to race it.

I prefer to just create an oplocked file in destination dir with same name as the rename will create. On oplock trigger I rename the oplock file to another directory and make the directory into a junction folder- then I acknowledge the trigger.

Not many people are aware that when oplock triggers we are in a weird quantum state where we can still change the outcome. We cannot delete the oplocked file, but by renaming it to other directory we get the same effect. So we can actually trigger an oplock on a file

and move it away so the the opener gets a nu such file. As it never was there. Using that you can make real oplocks that pause the caller on a file named the same as a directory. On trigger you switch the directory in instead with rename operations :)