-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Publish bundled binary on Windows loses execution permission #8006
Comments
Can you provide a reproduction or more details? I did a quick test with packaging a project with an executable, and the executable retained its permissions. |
I published protobuf-build 0.11.0 on Windows and downloaded it on Linux, only to find that binaries in bin directory has permissions 644. I published it again using the same single step |
You can test it without uploading. Take protobuf-build as an example:
|
Ah. AFAIK, Windows doesn't exactly have the same concept of POSIX permission modes (there is no "execute" bit). More or less we only know if something is a directory or file, and whether or not it is readonly. If you extract the archive on Windows, you should see that the If this is being published for other platforms, I would recommend not publishing from windows. |
Or we can fix it by reading files from git. Actually using git to build an archive on Windows preserve the permission bits.
|
That sounds interesting! Cargo uses the |
We currently slurp up filesystem permissions here and on Windows files are always 0o644 (or 0o444 but that's not too relevant). We can pretty easily tweak the tar header and set different permissions, but we'll need a location to source them from. If git's got all the information though seems reasonable to read it from there! |
I understand that this is how the |
We have #4413 for warning people against distributing binaries. |
### What does this PR try to resolve? This adds a special case for checking source files are symlinks and have been modified when under a VCS control This is required because those paths may link to a file outside the current package root, but still under the git workdir, affecting the final packaged `.crate` file. ### How should we test and review this PR? Pretty similar to #14966, as a part of #14967. This may have potential performance issue. If a package contains thousands of symlinks, Cargo will fire `git status` for each of them. Not sure if we want to do anything proactively now. The introduction of the `PathEntry` struct gives us more room for storing file metadata to satisfiy use cases in the future. For instances, * Knowing a source file is a symlink and resolving it when packaging on Windows * #5664 * #14965 * Knowing more about a file's metadata (e.g. permission bits from Git) * #4413 * #8006 * Provide richer information for `cargo package --list`, for example JSON output mode * #11666 * #13331 * #13953
Problem
When publishing a crate with bundled binaries on Windows, all the permission of binaries become 644.
Possible Solution(s)
Publish it on *nix instead.
Notes
Output of
cargo version
cargo 1.40.0 (bc8e4c8 2019-11-22)
The text was updated successfully, but these errors were encountered: