-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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/7.0] Implement proper File System detection for Apple OSes #74560
Conversation
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsBackport of #74493 to release/7.0 /cc @adamsitnik Customer ImpactTestingRiskIMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
cc @danmoseley |
The build failure is #74179 |
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.
Clean backport, LGTM.
@danmoseley can we get an approval for this backport? |
wrt risk -- on Linux, I see the codepath is unchanged. On Apple, is it possible there are other cases where statfsArgs.f_type is correct today, but statfsArgs.f_fstypename (which we now use) is not? If we do introducing a bug here, it looks like the only effect will be to potentially change whether we take an advisory lock or not. That's not good, but perhaps not a disaster either. would it break any functionality? (other than potentially not fixing this NFS copying)? typically we would not take a fix at this stage that wasn't a regression, or at least serious. However, I think we would potentially service for this. So I'm open to taking it but interested in answers to qs above. |
f_type is unreliable on macOS, as metioned here. I think this is better than what we currently have. |
@adamsitnik are there any tests that were disabled for macOS due to this issue and that now can be re-enabled? I couldn't find any but you probably know better. |
Right, but if hypothetically macOS reported the correct statfsArgs.f_type but wrong statfsArgs.f_fstypename for smb, smb2, cifs (since those are the other 4 we will not lock for) we will start locking, when we did not before. And reverse for other file systems, but in that case not locking when we did, which is less significant.
This is hypothetical, I'm just trying to think through all possibilities. |
I very much doubt that. Based on the research I did it's exactly the opposite (
In theory it's possible that so far, we were not able to recognize the file system on some apple OSes and we were not locking the files even when we should have: runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.Unix.cs Lines 457 to 460 in 5764faf
And now we are going to start locking them, as expected. Which might fix a silent error (users using files thinking they have exclusive access, while they don't). Even if in theory we miss some case users can still request no locking via config switch: runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.Unix.cs Lines 37 to 38 in 5764faf
there are none, as we never had any NFS tests: #54495 |
OK, approved, as we would potentially service for this as it's a fairly basic scenario, no workaround, customer reported. Thanks for the info above. |
Thanks for the approval. |
Will this be backported to 6.0 ? |
Backport of #74493 to release/7.0
/cc @adamsitnik
Customer Impact
Customers using macOS can't write to files located on NFS shares. We have fixed this bug in 6.0 for Linux (#55256), but it was not tested for maOS. It turned out that file system detection was not working properly on macOS, as data populated by
fstatfs
was containing an OS version specific file system id.Example taken from StackOverflow: autofs was recognized as
25
for macOS 10.12 and as24
for macOS 10.13.Official Apple documentation refers to it as:
The fix was to rely on the string populated by the sys-call. The mapping logic already existed and was used by BSD-like systems.
Testing
An assert that verifies that File System is always recognized was added.
Risk
The risk is very low:
runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.Unix.cs
Lines 457 to 460 in 5764faf