-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.107.3
Pipeline Utility Steps 2.1.0
Run this pipeline:
node() {
// create an example ZIP file
sh '''\
base64 -d > test.zip << EOF
UEsDBAoAAAAAAJ2SrkwAAAAAAAAAAAAAAAAIABwAdGVzdC5iaW5VVAkAA1qp+VpaqfladXgLAAEE
6AMAAAToAwAAUEsBAh4DCgAAAAAAnZKuTAAAAAAAAAAAAAAAAAgAGAAAAAAAAAAAAP2BAAAAAHRl
c3QuYmluVVQFAANaqfladXgLAAEE6AMAAAToAwAAUEsFBgAAAAABAAEATgAAAEIAAAAAAA==
EOF'''.stripIndent()
sh 'unzip -o test.zip && ls -l test.bin && rm test.bin'
unzip zipFile: 'test.zip', quiet: true
sh 'ls -l test.bin'
}
The (relevant) output is:
+ ls -l test.bin -rwxrwxr-x 1 jenkins jenkins 0 May 14 15:20 test.bin ... + ls -l test.bin -rw-r--r-- 1 jenkins jenkins 0 May 14 15:51 test.bin
You can see that the native unzip program extracts the file with the permissions it actually has in the archive (775), while the unzip step extracts it with default permissions (644).
- relates to
-
-
- Open
-
[JENKINS-51303] unzip step doesn't set permissions on extracted files
aby abo
added a comment - I am having the same issue using the built-in zip function 
Kalle Niemitalo
added a comment - I changed the status from In Progress back to Open, because the user who started the progress is no longer active and I didn't find any related pull request.
Kalle Niemitalo
added a comment - I changed the status from In Progress back to Open, because the user who started the progress is no longer active and I didn't find any related pull request. Kalle Niemitalo
added a comment - I looked at how the zip and unzip steps are implemented.
The unzip step copies the file content as a stream and does not attempt to set the file modes, so this is clearly a missing feature there.
In contrast, the zip step calls ArchiverFactory.ZIP.create and then Archiver.visit, i.e. ZipArchiver.visit, which attempts to save the file mode:
If the zip step loses the permissions regardless, then the problem might be caused by JENKINS-53874, in which case it should be fixed in the Jenkins core. (The "version made by" and "external file attributes" fields described in APPNOTE.TXT - .ZIP File Format Specification are relevant. JENKINS-64818 is similar but not the cause here, because it applies to VirtualFile.zip rather than ZipArchiver.)
Kalle Niemitalo
added a comment - I looked at how the zip and unzip steps are implemented.
The unzip step copies the file content as a stream and does not attempt to set the file modes, so this is clearly a missing feature there.
UnZipFileCallable.invoke calls FilePath.write and then IOUtils.copy
In contrast, the zip step calls ArchiverFactory.ZIP.create and then Archiver.visit, i.e. ZipArchiver.visit, which attempts to save the file mode:
ZipItFileCallable.invoke calls Archiver.visit
ZipArchiver.visit calls ZipEntry.setUnixMode
If the zip step loses the permissions regardless, then the problem might be caused by JENKINS-53874 , in which case it should be fixed in the Jenkins core. (The "version made by" and "external file attributes" fields described in APPNOTE.TXT - .ZIP File Format Specification are relevant. JENKINS-64818 is similar but not the cause here, because it applies to VirtualFile.zip rather than ZipArchiver.)
Complementary to this, the zip step does not appear to preserve file permissions in the created archive.
rsandell, is it fair to assume that both of these issues would be addressed at the same time?