Closed tarekgh closed 3 years ago
Tagging subscribers to this area: @maryamariyan, @dotnet/area-extensions-filesystem See info in area-owners.md if you want to be subscribed.
Author: | tarekgh |
---|---|
Assignees: | - |
Labels: | `area-Extensions-FileSystem`, `untriaged` |
Milestone: | - |
I think this is because retrieval of the link is not atomic and happens when the file no longer exists between the call to LinkTarget
and ResolveLinkTarget
.
https://github.com/dotnet/runtime/blob/47e82c1f625428c02eb6b31d7a7400c53a8c24b9/src/libraries/Microsoft.Extensions.FileProviders.Physical/src/Internal/FileSystemInfoHelper.cs#L52-L57
A couple of options:
TryResolveLinkTarget
API that doesn't throw on IO errors.cc @adamsitnik @carlossanlop @jeffhandley
To be clear, my suggestion also involves public APIs for getting the modified time on the target of link. The prototype i shared did it internally which should be avoided if we’re making IO changes. If we need it customers should get it too.
This started in the last two days: https://runfo.azurewebsites.net/search/tests/?q=started%3A%7E7+definition%3Aruntime+name%3A%22Microsoft.Extensions.FileProviders.Physical.Tests%22 Somehow it's able to crash XUnit. @Jozkee is it possible to disable anything that will unblock this? It's quickly becoming a heavy hitter.
is it possible to disable anything that will unblock this?
Yes.
Seems that all the errors are on OSX and Linux, can we just disable the tests for those platforms? I still would like to see what issues could occur in windows since local repro is hard.
https://github.com/dotnet/runtime/pull/56183/checks?check_run_id=3138813912 https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-56183-merge-f78074ea8e6047b2a6/Microsoft.Extensions.FileProviders.Physical.Tests/console.ac3f3b03.log?sv=2019-07-07&se=2021-08-11T22%3A22%3A03Z&sr=c&sp=rl&sig=ywBXxPkq8EuFYEZl2jIf5dvaPIqJDBOgm1Phou2QmU0%3D