-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/6.0] SafeFileHandle.Unix: don't DeleteOnClose when lock is not successful. #60112
Conversation
In dotnet#55153 DeleteOnClose handling moved from FileStream to SafeFileHandle. This unintentionally caused DeleteOnClose to be applied even when FileShare locking fails. As on Windows, DeleteOnClose should not take effect when sharing prevents the file from being opened. This also swaps the order of unlink and LOCK_UN in Dispose as it was prior to dotnet#55153. Either order should be fine.
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsIn #55153 DeleteOnClose handling This unintentionally caused DeleteOnClose to be applied even when This also swaps the order of unlink and LOCK_UN in Dispose as it was Fixes #59995. @stephentoub @dotnet/area-system-io ptal. This targets release/6.0 branch. It is a subset of changes from #55327 which tackles a broader issue.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, big thanks for the fix @tmds!
I made an attempt at formatting the initial comment into the 'backport' format. @stephentoub will you look into the servicing considerations? |
@jeffhandley this PR is ready for being considered for merging to 6.0 |
What is the motivation for porting this part? Would it be lower risk to just port the fix itself? |
The unlink and flock use distinct variables and both ignore errors. I see no additional risk by swapping them. |
Approved by tactics. Some of the failing checks were in the IO area; rerunning... |
WASM failures are tracked by #51961 (comment) @jeffhandley let me know if you'd like me to use my super merging powers |
I'm going to be bold and merge... |
Thanks for merging, @danmoseley. And thanks for the fix, @tmds! |
Description
In #55153 DeleteOnClose handling moved from FileStream to SafeFileHandle.
This unintentionally caused DeleteOnClose to be applied even when FileShare locking fails. As on Windows, DeleteOnClose should not take effect when sharing prevents the file from being opened.
This also swaps the order of unlink and LOCK_UN in Dispose as it was prior to #55153.
Either order should be fine.
Customer impact
Unintentional deleting of file.
Testing
Existing and new unit test.
Risk
Low. Behaves the same as previous versions of .NET.
Fixes #59995.