Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Undesired handle inheritance (SECURITY_ATTRIBUTES bInheritHandle)

See original GitHub issue

I’ve noticed that AlphaFS does not include bInheritHandle in its SECURITY_ATTRIBUTES mapping and am wondering whether that results in undefined or undesired behavior.

See the .NET Framework implementation here for comparison: Reference Source.

I suspect that file handles create by AlphaFS result in the bInheritHandle being set to 1 always or randomly.

Can you comment on that suspicion?

I am currently tracking the following behavior:

Open file for writing: fileInfo.Open(FileMode.Create, FileAccess.Write, FileShare.None)
Start writing data to the stream (in chunks of 4096 bytes) with a StreamWriter
Create child process via Process.Start on a different thread (not related to that file operation and working in a different directory) while the file handle is still open.
Finish writing and dispose the FileStream and StreamWriter
Observe (in Process Monitor) that any writes and the close after the child process start don’t get executed by Windows until the child process exits.
Also observe that code execution continues (no block on dispose/close) but that the file is locked as subsequent file operations (e.g. read) fail until the child process exits.
When the child process exits it closes the file handle.

In other words: Any open file handles that are inheritable get passed along to any spawning child processes and result in locking of those files for the duration of the process lifetimes.

From what I gather, applicable handles get inherited by child processes with the .NET process creation. File handles are applicable under some circumstances (See here. While the resulting behavior is strange, it does appear to be the intended behavior (as far as inheritance is concerned).

I’ll try switching the code parts to the System.IO classes and see if that fixes the issue and report back.