-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Implement UnixFileMode APIs #69980
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
Implement UnixFileMode APIs #69980
Changes from 39 commits
11c2422
b182b4d
f143499
5138601
4d6c524
813e24a
7bd2ae3
d67d738
3841bfb
d1e7ea8
f7db626
88828a4
cd4104f
c937c28
a12832c
d294651
3df946a
f3c55bf
91e0891
6e74d98
757c1e5
53539ec
873660e
d9c7789
3dba808
33d3e6f
18e70c9
b2423c6
777b77d
4e93e11
60d24a7
8f8ff2d
97df035
7bfa541
01f6ff3
6e91cf1
4cb6316
7046ea9
e55011d
bc7383b
d1f043d
168bdf5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -59,7 +59,6 @@ | |
| <Compile Include="$(CommonPath)Interop\Unix\System.Native\Interop.FChMod.cs" Link="Common\Interop\Unix\System.Native\Interop.FChMod.cs" /> | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| <Compile Include="$(CommonPath)Interop\Unix\System.Native\Interop.Link.cs" Link="Common\Interop\Unix\System.Native\Interop.Link.cs" /> | ||
| <Compile Include="$(CommonPath)Interop\Unix\System.Native\Interop.MkFifo.cs" Link="Common\Interop\Unix\System.Native\Interop.MkFifo.cs" /> | ||
| <Compile Include="$(CommonPath)Interop\Unix\System.Native\Interop.Permissions.cs" Link="Common\Interop\Unix\Interop.Permissions.cs" /> | ||
tmds marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| <Compile Include="$(CommonPath)Interop\Unix\System.Native\Interop.Stat.cs" Link="Common\Interop\Unix\Interop.Stat.cs" /> | ||
| <Compile Include="$(CommonPath)System\IO\Archiving.Utils.Unix.cs" Link="Common\System\IO\Archiving.Utils.Unix.cs" /> | ||
| </ItemGroup> | ||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -3,6 +3,7 @@ | |||||||||||||
|
|
||||||||||||||
| using System.Diagnostics; | ||||||||||||||
| using Microsoft.Win32.SafeHandles; | ||||||||||||||
| using System.IO; | ||||||||||||||
|
|
||||||||||||||
| namespace System.Formats.Tar | ||||||||||||||
| { | ||||||||||||||
|
|
@@ -53,7 +54,9 @@ partial void SetModeOnFile(SafeFileHandle handle, string destinationFileName) | |||||||||||||
| // If the permissions weren't set at all, don't write the file's permissions. | ||||||||||||||
| if (permissions != 0) | ||||||||||||||
| { | ||||||||||||||
| Interop.CheckIo(Interop.Sys.FChMod(handle, permissions), destinationFileName); | ||||||||||||||
| #pragma warning disable CA1416 // Validate platform compatibility | ||||||||||||||
|
||||||||||||||
| <ItemGroup Condition="'$(TargetPlatformIdentifier)' == 'Unix'"> | |
| <Compile Include="System\Formats\Tar\TarEntry.Unix.cs" /> |
Is it expected that the compiler produces warning?
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.
It is not expected, maybe it is loaded in cross platform build? What is the whole warning message? Message includes the call site info
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.
I added it by mistake to TarEntry.Unix.cs. It is only required for ZipFileExtensions.ZipArchiveEntry.Extract.Unix.cs.
And there it makes sense because the file is included in $(NetCoreAppCurrent) target.
/home/tmds/repos/runtime/src/libraries/System.IO.Compression.ZipFile/src/System/IO/Compression/ZipFileExtensions.ZipArchiveEntry.Extract.Unix.cs(26,17): error CA1416: This call site is reachable on all platforms. 'File.SetUnixFileMode(SafeFileHandle, UnixFileMode)' is unsupported on: 'windows'. [/home/tmds/repos/runtime/src/libraries/System.IO.Compression.ZipFile/src/System.IO.Compression.ZipFile.csproj]
The csproj file has:
runtime/src/libraries/System.IO.Compression.ZipFile/src/System.IO.Compression.ZipFile.csproj
Line 4 in 3282677
| <TargetFrameworks>$(NetCoreAppCurrent)-windows;$(NetCoreAppCurrent)</TargetFrameworks> |
and
runtime/src/libraries/System.IO.Compression.ZipFile/src/System.IO.Compression.ZipFile.csproj
Lines 25 to 27 in 3282677
| <ItemGroup Condition="'$(TargetPlatformIdentifier)' == ''"> | |
| <Compile Include="System\IO\Compression\ZipFileExtensions.ZipArchive.Create.Unix.cs" /> | |
| <Compile Include="System\IO\Compression\ZipFileExtensions.ZipArchiveEntry.Extract.Unix.cs" /> |
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.
The TFMs on this project seem incorrect to me. It has changed quite a few times in the last year.
- When I made it respect file modes in Compression.ZipFile support for Unix Permissions #55531 to have a separate "Unix" build
- @ViktorHofer changed it to have an "agnostic" TFM (basically the "Windows" build) in Add NetCoreAppCurrent rid agnostic tfm to libs #64518
- Lastly in April with Added test for extracting zip files with invalid characters in Windows #67332 to add back a "Windows" TFM and make the "unix" side the agnostic build.
So unfortunately, because of these TFM changes, the "Unix" build doesn't get the attribute that says "this isn't Windows", which means the analyzer is handicapped here.
Instead of disabling the warning, I think just adding Debug.Assert(!OperatingSystem.IsWindows()); at the top of the method would be best for now. Long term, I hope we can settle on a manageable TFM plan.
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.
Long term, I hope we can settle on a manageable TFM plan.
@eerhardt can you please elaborate on why you think that the current strategy of choosing target frameworks isn't manageable? cc @ericstj
Some libraries intentionally define a TargetPlatform agnostic target framework which serves as the default configuration to reduce the number of inner builds in the build graph. Such a TargetPlatform agnostic target framework is either truly platform agnostic or it targets a specific platform that is believed to be a good default (in most / all cases Unix).
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.
@buyaa-n @ViktorHofer the File.SetUnixFileMode method is marked as [System.Runtime.Versioning.UnsupportedOSPlatformAttribute("windows")] and this particular C# file is compiled only for Unix:
The SDK unconditionally adds supported platforms and one of those is Windows. The SDK itself doesn't make it possible to only target Windows, macOS or Linux via a target platform, but we in dotnet/runtime allow that via the Microsoft.DotNet.TargetFramework.Sdk.
Because of that, we would need to remove these unconditionally set SupportedPlatform items and instead add them conditionally similar to how it is done for Browser.
Here you can see that the SupportedPlatform metadata is added for Browser when the platform is Browser, or when it's agnostic and the library doesn't have a Browser specific implementation.
I think we would want the same for Unix and for any other platform.
EDIT:
Please see ViktorHofer#2 (my fork, just to get feedback). That logic calculates the SupportedPlatforms items correctly based on the RID graph. This implementation is completely static but solves the noted issues.
To make this dynamic, an msbuild task in the TargetFramework.Sdk would be required that takes the build rid graph (OSGroups.json), TargetFrameworks, TargetFramework and TargetPlatformIdentifier as an input and outputs the SupportedPlatform item to be added.
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.
The SDK unconditionally adds supported platforms and one of those is Windows. The SDK itself doesn't make it possible to only target Windows, macOS or Linux via a target platform, but we in dotnet/runtime allow that via the Microsoft.DotNet.TargetFramework.Sdk.
SDK supported platforms cause warnings only for cross platform targets, has no effect targeted builds. I might missing something but still do not understand why we could not use Linux or Unix targets for the above mentioned build and keep the $(NetCoreAppCurrent) only for real cross platform targets.
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.
Moved the discussion into #71251.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,7 +22,9 @@ static partial void ExtractExternalAttributes(FileStream fs, ZipArchiveEntry ent | |
| // include the permissions, or was made on Windows. | ||
| if (permissions != 0) | ||
| { | ||
| Interop.CheckIo(Interop.Sys.FChMod(fs.SafeFileHandle, permissions), fs.Name); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can the Interop file be removed from this .csproj? |
||
| #pragma warning disable CA1416 // Validate platform compatibility | ||
| File.SetUnixFileMode(fs.SafeFileHandle, (UnixFileMode)permissions); | ||
| #pragma warning restore CA1416 | ||
| } | ||
| } | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.