-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Copy task can't copy symlink to directory #6821
Comments
…eworks to the app bundle. Fixes xamarin#12369. .NET/MSBuild don't handle symlinks properly [1], which means that we can't ask .NET to copy frameworks to the app bundle, since frameworks may contain symlinks. In our case, the symptom was that instead of copying symlinks, the file the symlink pointed to was copied instead, and then codesign complained about invalid bundle format when we tried to sign the framework. We fix this by having our own target (_CopyFrameworksToBundle) to copy frameworks to the app bundle (instead of adding all the files in the frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to copy the frameworks. [1]: dotnet/msbuild#6821 Fixes xamarin#12369.
…opy frameworks to the app bundle. Fixes #12369. (#12656) .NET/MSBuild don't handle symlinks properly [1], which means that we can't ask .NET to copy frameworks to the app bundle, since frameworks may contain symlinks. In our case, the symptom was that instead of copying symlinks, the file the symlink pointed to was copied instead, and then codesign complained about invalid bundle format when we tried to sign the framework. We fix this by having our own target (_CopyFrameworksToBundle) to copy frameworks to the app bundle (instead of adding all the files in the frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to copy the frameworks. In order to create a test case for this, I also made the macOS and Mac Catalyst versions of the XTest framework use symlinks: * Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst by using the typical symlink structure (actual files in the Versions/A subdirectory, and then symlinks pointing into that directory). * Create a separate Info.plist for each platform for XTest.framework, since using an otherwise correct framework makes tooling (such as codesign) complain if the Info.plist isn't correct too. This made our existing tests show the bug. Finally I had to fix signing frameworks where the executable is a symlink. We were first resolving symlinks for the input - say we had an Example.framework/Example symlink to Example.framework/Versions/A/Example - and then checking the parent directory if it's a framework. The parent directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet our framewrok condition (if it ends with '.framework'). The fix is to adjust the logic to resolve symlinks after checking if the input is a framework or not. [1]: dotnet/msbuild#6821 Fixes #12369.
In general MSBuild is not very aware of symlinks; we tend to try to see through them to find "real files". I suspect this is #703. Is this super painful for y'all? We can reevaluate symlinks as inputs to Copy but it'll take some design effort (since we'll need to preserve the "if you copy a linked file it copies the contents of the file, not the link itself" behavior we've had for a long time). |
I've been able to work around it so far by not using the Copy task when we might run into a symlink.
One thing that would be helpful would be to make Copy able to copy a directory (and in that case preserve all the contents as-is, including symlinks) - I believe this has been filed already though (#5881). |
This issue is marked as stale because feedback has been requested for 30 days with no response. Please respond within 14 days or this issue will be closed due to inactivity. |
I did respond, see previous comment. |
Team Triage: Since there's a workaround we're going to put this in the backlog, but we're not opposed to finding a solution for this. |
Repro:
symlinks-9c50e79.zip
Download, extract and run "make sucess" or "make fail" depending on what you want to test.
I'm trying to copy a symlink that points to a directory. That fails with:
Now I remove the directory the symlink points to (so that the symlink points to nowhere).
This rather strangely works just fine.
The problem seems to be that the Copy task doesn't consider symlinks as files when they point to a directory.
Binlogs:
binlogs.zip
The text was updated successfully, but these errors were encountered: