skip the test when dotnet.exe is locked #66196
Conversation
adamsitnik
added
area-System.IO
test-enhancement
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsI've tried to repro #65820 and of course I've failed to do that. However, I was able to repro the same exception by opening the dotnet.exe for writing with exclusive file access before starting the process: ProcessStartInfo startInfo = new ProcessStartInfo()
{
FileName = @"C:\Program Files\dotnet\dotnet2.exe",
Arguments = "--info",
RedirectStandardOutput = true, // avoid visible output
UseShellExecute = false
};
var fs = new FileStream(startInfo.FileName, FileMode.Open, FileAccess.ReadWrite, FileShare.None, 4096, false);
Console.WriteLine(fs.Length);
using Process dotnet = Process.Start(startInfo);
dotnet.WaitForExit();
fs.Dispose();In the perfect world, I would enable ETW logging for file events on the CI machines and find out who is locking the file and why, but in my opinion it would take more time than it's worth it. So to tell the long story short I think that we can just skip this test when fixes #65820
|
|
/azp list |
|
/azp run runtime-libraries-coreclr outerloop-windows |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@danmoseley @jozkee ping |
| { | ||
| hasStarted = p.Start(); | ||
| } | ||
| catch (Win32Exception ex) when (ex.NativeErrorCode == ERROR_SHARING_VIOLATION) |
There was a problem hiding this comment.
I guess this covers "The process cannot access the file because it is being used by another process.", Does it cover "Access is denied." as well?
There was a problem hiding this comment.
@jozkee good catch! I've extended the current logic that was granting access to the executable file to also provide access to the working directory. I hope it fixes the issue. PTAL
|
Another approach could be to add this utility somewhere, although I think would not work for very transient locks as ETW would. |
|
/azp run runtime-libraries-coreclr outerloop-windows |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-libraries-coreclr outerloop-windows |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
inner loop failure is #67948 |
I've tried to repro #65820 and of course I've failed to do that.
However, I was able to repro the same exception by opening the dotnet.exe for writing with exclusive file access before starting the process:
In the perfect world, I would enable ETW logging for file events on the CI machines and find out who is locking the file and why, but in my opinion it would take more time than it's worth it. I think that we can just skip this test when
dotnet.exeis locked.fixes #65820