installer
installer copied to clipboard
Too many files are marked executable
Too many files are marked executable. (while I've only looked at the osx-arm64 build, I would guess this is a general problem.
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f | wc -l
498
The reasonable set of executable binaries would be these. (apphost
and singlefilehost
templates are debatable).
steve@Toms-Mac-2 helloWorld % find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -not '(' -name \*.dll -o -name \*.dylib -o -name \*.xml -o -name \*.txt -o -name \*.a -o -name \*.h ')'
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/shared/Microsoft.NETCore.App/6.0.0-alpha.1.20624.8/createdump
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/dotnet
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Host.osx-arm64/6.0.0-alpha.1.20624.8/runtimes/osx-arm64/native/apphost
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Host.osx-arm64/6.0.0-alpha.1.20624.8/runtimes/osx-arm64/native/singlefilehost
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/sdk/6.0.100-alpha.1.20625.2/AppHostTemplate/apphost
We are marking dll
, xml
, dylib
, txt
, h
and a
extensions executable. None of these represent executable programs.
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.dll | wc -l
318
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.xml | wc -l
153
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.dylib | wc -l
14
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.txt | wc -l
4
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.h | wc -l
3
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.a | wc -l
1
This issue probably belongs in another repo (arcade?), but symptoms cross dependent repos
% for i in $(find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f '(' -name \*.dll -o -name \*.dylib -o -name \*.xml -o -name \*.txt -o -name \*.a -o -name \*.h ')' | sort -f ); do dirname $i; done | sort -f | uniq
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/host/fxr/6.0.0-alpha.1.20624.8
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.AspNetCore.App.Ref/6.0.0-alpha.1.20624.2/data
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.AspNetCore.App.Ref/6.0.0-alpha.1.20624.2/ref/net6.0
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Host.osx-arm64/6.0.0-alpha.1.20624.8/runtimes/osx-arm64/native
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Ref/6.0.0-alpha.1.20624.8/data
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Ref/6.0.0-alpha.1.20624.8/ref/net6.0
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/NETStandard.Library.Ref/2.1.0/data
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/shared/Microsoft.NETCore.App/6.0.0-alpha.1.20624.8
/cc @jkoritzinsky @ViktorHofer @mmitche
@dagood to take a look.
I checked an apphost tar.gz output from a dotnet/runtime daily build and the problem isn't there in the original artifact. (Except for libnethost.dylib
.) dotnet-apphost-pack-6.0.0-alpha.1.21056.6-osx-arm64.tar.gz
:
vs. dotnet-sdk-6.0.100-alpha.1.21056.8-osx-arm64.tar.gz
from dotnet/installer readme:
This target looks like it's doing this intentionally:
https://github.com/dotnet/installer/blob/01930deb2a897ba302d89dacbe15a0622f2ecf0c/src/redist/targets/Crossgen.targets#L158-L164
/cc @NikolaMilosavljevic FYI
(
apphost
andsinglefilehost
templates are debatable).
For anyone curious what this means, there's a thread about it at https://github.com/dotnet/runtime/issues/3843.
- I don't think most/any of the SDK files should be writable either.
- Execute permissions should be for all users too.
@dagood Hmmm
<Exec Command="find $(SdkOutputDirectory) -type f -exec chmod 644 {} \;" />
On second thought 644
is rw-r--r--
so that is not the correct root cause.
Oh... right. 😄 Well, the nupkgs (Microsoft.NETCore.App.Host.osx-arm64
) don't persist permission bits and NuGet restore extracts them as 744, which matches. I guess the SDK layout uses the nupkg
s, not the tar.gz
s.
I did look at the preview1 installer. The dlls are not marked executable. The dylibs
are though. Per @janvorli, XCode marks dylibs as executable by default and we have just left them as executable.
I di see that when we published --self-contained
the sdk installed the dlls as executable though.
Did this end up getting fixed in 6.0.100 and can be closed? Reactivate if not.
This hasn't changed. Here's a fresh screenshot of dotnet-sdk-6.0.100-osx-arm64.tar.gz
packs\Microsoft.NETCore.App.Host.osx-arm64\6.0.0\runtimes\osx-arm64\native\
:
@marcpopMSFT this is still a thing - the latest Linux binaries (8.0.300) have the executable bit marked on so many unnecessary files. When I extracted the tarball every file and directory in it had rwx permissions for user, group, and other.