View Issue Details [ Jump to Notes ]

[ Print ]

Project

Category

View Status

Date Submitted

Last Update

0012865

CMake

CPack

public

2012-01-09 11:47

2016-06-10 14:31

Reporter

muhkuh

Assigned To

Kitware Robot

Priority

low

Severity

minor

Reproducibility

always

Status

closed

Resolution

moved

Platform

MinGW

windows

OS Version

Product Version

CMake 2.8.7

Target Version

Fixed in Version

Summary

0012865: CPack generated archives don't have correct permissions when cross compiling on windows

Description

We have a cross toolchain running on windows that compiles code and builds install packages for linux and other unix like systems. When using CPack to create tar.gz installer packages the files in these archives don't have the execute file permission set for the executables and libraries.

Additional Information

My guess is that this happens because CPack relies on the hosts filesystem to have the file permissions as the cmake install target dictates. But this doesn't work when compiling under windows because NTFS doesn't support file permissions in this way.

It would be nice if cpack could get correct file permissions in a different way like reading a metadata file that cmake outputs but this might be too much work for this small problem. May be it would be sufficient to add an option to the cpack that allows the user to override permissions.

Tags

No tags attached.

Attached Files

Relationships

related to	0013193	closed	Eric NOULARD	All the Files in the Source Tarballs (from "make package_source" on UNIX-like platforms) Have Close (and Arbitrary) Timestamps
related to	0012142	closed	Kitware Robot	Read-only files lose their read-only attribute when packaged using either ZIP or NSIS

Notes
(0028218) Eric NOULARD (developer) 2012-01-09 13:00	Hi, Yes CPack relies on locally installed files in order to get the permission. Reading meta-data seems like an overkill feature. Did you check that locally installed files do have wrong permissions? The files should be located somewhere below <buildtree>/_CPack/.../TGZ/... Why wouldn't NTFS support execute permission?

(0028223) muhkuh (reporter) 2012-01-10 04:47	The locally installed files cmake creates have default permissions like all files created by me in my user folder. Usually on windows this is full access (everything: read, write, execute, change file attributes and so on). But this doesn't work like on unix systems where the execute file permission is used to make a file executable. On windows all file are executable as far as NTFS file access rights go. But only files with an .exe or .com extension are executable. Scripts and so on have to have a special extension so the system knowns how to run them. I hope I'm not boring you with stuff you already know but this is how I understood your question. So if CPack relies on file access rights on windows this basically means (IMHO) that there is no real equivalent for the unix execute file permission. This doesn't matter if an executable is created for windows itself as it will have the .exe extension and everything works as expected. But when cross compiling I get a tar archive with files that don't have the executable permission set.

(0030349) David Cole (manager) 2012-08-11 21:09	Sending old, never assigned issues to the backlog. (The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...) If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.

(0041960) Kitware Robot (administrator) 2016-06-10 14:28	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2012-01-09 11:47	muhkuh	New Issue
2012-01-09 13:00	Eric NOULARD	Note Added: 0028218
2012-01-10 04:47	muhkuh	Note Added: 0028223
2012-08-11 21:09	David Cole	Status	new => backlog
2012-08-11 21:09	David Cole	Note Added: 0030349
2012-08-12 03:12	Eric NOULARD	Relationship added	related to 0013193
2013-03-08 07:44	Eric NOULARD	Relationship added	related to 0012142
2016-06-10 14:28	Kitware Robot	Note Added: 0041960
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed