We get always the exception for a blob-file that ... it could not be opened because it is being used by another process. This exception is thrown by the exception handler in filter.cs , Log.Write(LogLevel.Error, "Filter.StreamWriteCallback exception"); It seems that you rely on exclusive file access when using the stream writer (StreamWriteCallback) with the FileShare.None option. But that assumption may not be correct in this case. git_futils_open_ro opens the blob file in question (read mode), and the file is still open while the stream writer in C is starting. We could trace the file handle on Windows. We follow your advice and use the LibGit2TestPath environment variable to be sure that we have complete control over the output test folder, and we observed that Resource Monitor reports the blob file as being locked by the test engine itself. This is our call stack:
We get always the exception for a blob-file that
... it could not be opened because it is being used by another process. This exception is thrown by the exception handler infilter.cs,Log.Write(LogLevel.Error, "Filter.StreamWriteCallback exception");It seems that you rely on exclusive file access when using the stream writer (StreamWriteCallback) with theFileShare.Noneoption. But that assumption may not be correct in this case.git_futils_open_roopens the blob file in question (read mode), and the file is still open while the stream writer in C is starting. We could trace the file handle on Windows. We follow your advice and use theLibGit2TestPathenvironment variable to be sure that we have complete control over the output test folder, and we observed that Resource Monitor reports the blob file as being locked by the test engine itself. This is our call stack: