-
Notifications
You must be signed in to change notification settings - Fork 5.1k
use O_TRUNC when file locking is disabled, avoid ftruncate syscall #55456
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
Conversation
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsWhen locking is enabled and the user requests the file to be truncated, it's opened, then locked and then truncated via When locking is disabled, we can use
|
src/libraries/Common/tests/TestUtilities/System/PlatformDetection.cs
Outdated
Show resolved
Hide resolved
<!-- file locking can't be disabled on Windows --> | ||
<TargetFrameworks>$(NetCoreAppCurrent)-Unix</TargetFrameworks> |
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.
Can we instead have this run everywhere, and have the test changed to be:
Assert.Equal(OperatingSystem.IsWindows(), PlatformDetection.IsFileLockingEnabled);
?
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.
This project includes all test files that are run for System.IO.FileSystem.Tests.csproj
. If we enable it for Windows, we are basically going to run the same tests with the same config twice on Windows. Why would we want to do that?
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.
Why do we want to do it on Unix? The setting controls a minority of functionality. Shouldn't we be more scoped?
Regardless, my point was that your comment asserts this property, which now controls whether multiple tests run, will always be true on Windows. Seems like a good thing to validate with the test you're adding.
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.
Why do we want to do it on Unix?
My main motivation is to make sure that file IO actually works as expected when the locking is disabled. It's unlikely that we introduce a bug in this code path, but it's still possible.
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.
Sure, but running all 6000+ tests?
case FileMode.Open: // Open maps to the default behavior for open(...). No flags needed. | ||
case FileMode.Truncate: // We truncate the file after getting the lock | ||
case FileMode.Truncate when !DisableFileLocking: // We truncate the file after getting the lock |
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.
Rather than duplicating the case for Truncate and Create, I'd rather see this be something like:
case FileMode.Truncate:
if (DisableFileLocking)
{
flags |= Interop.Sys.OpenFlags.O_TRUNC; // if we don't lock the file, we can truncate it when opening
}
break;
That way, everything about Truncate is contained in one case, and I don't have to go searching for all the different when combinations to figure out whether everything is covered.
Same for the other modes.
}
Co-authored-by: Stephen Toub <[email protected]>
When locking is enabled and the user requests the file to be truncated, it's opened, then locked and then truncated via
ftruncate
syscall.When locking is disabled, we can use
O_TRUNC
when opening the file and avoid theftruncate
syscall.