[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612522#comment-17612522
 ] 

Herve Boutemy commented on MASSEMBLY-941:
-----------------------------------------

ok, now I start to remember the compromises I had to do both for UID/GID and 
file/dir permissions in tar archives in 
https://github.com/codehaus-plexus/plexus-archiver/pull/121

UID/GID seems ok, nobody complains

but file/dir permission is not ok: IIRC, the issue I got is variation based on 
user's umask on Unixes
= user/group/other
user permissions are ok, but group and other may differ based on umask

idea: instead of ignoring file permissions, perhaps we could store in the 
archive the same permissions for group and other than user?
WDYT?

[~plamenttv] we had a small discussion on these file permissions in 
https://github.com/codehaus-plexus/plexus-archiver/pull/121

> file permissions removed during assembly:single since 3.2.0
> -----------------------------------------------------------
>
>                 Key: MASSEMBLY-941
>                 URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
>             Project: Maven Assembly Plugin
>          Issue Type: Bug
>          Components: permissions
>    Affects Versions: 3.2.0, 3.3.0
>            Reporter: Christopher Tubbs
>            Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to