IRP_MJ_CREATE and $Recycle.Bin path

So I can from time to time get a IRP_MJ_CREATE with the filename as
“$Recycle.Bin\S-1-5-21-1094529100-1738202490-1165505843-1002.???”
and I call RtlUnicodeToUTF8N() to convert which returns STATUS_SOME_NOT_MAPPED.

That in itself is not really an issue, I can figure out something to do there.

The IRP_MJ_CREATE comes with SL_OPEN_TARGET_DIRECTORY so it wants the parent that contains the file.

But, what is it expecting? The path does not start with "", it starts with “$Recycle”. I have no such dir, but it is asking for the parent of it, should I return "" or some form of error? I have not found any special-case code regarding “$Recycle.Bin” in the Windows-driver-samples.

In this case, it is passing in FileObject->RelatedFileObject, a directory, should I return that? Or am I overthinking it, it is passing a dir, and a file/dir to lookup inside it, that does not exist, so it should just fail.

Yeah I think I’m just overthinking it - the object doesn’t exist, return error.

No, you are not overthinking this. You are just missing the import of the related file object and, critically, of SL_OPEN_TARGET_DIR.

If in doubt, read FAT, but the general idea is that this is the name that a file is going to have after after a rename operation. The name, of course,is affected by the specification of a related FO, just like any other create.

Most filesystems that I’ve spelunked return the parent dir, and FAT squirrels the new name away in the CCB so when the file object turns up in the SetFileRename it knows what to do. Of course the new name may be specified there as well. Renames is grotesque.

If you fail the create the rename will fail and in this case explorer will do something else.

Yep, I couldn’t even “git clone” as a test, it needs it to succeed for non-existent things.