[GRADLE-2844] Tar and untar losing symbolic links Created: 20/Jul/13  Updated: 03/Feb/17  Resolved: 03/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Duplicate Votes: 8


 Description   

Running on CentOS 6.3. Gradle 1.7-rc-1.
I've defined an artifact which is a tarball that contains symbolic links. The assemble step creates the tarball correctly:

$ tar tvzf boost-1.52-slc01-native.tgz

drwxr-xr-x root/root 0 2013-07-16 15:00 lib/
rw-rr- root/root 135948 2013-07-16 14:49 lib/libboost_date_time.a
rw-rr- root/root 225978 2013-07-16 14:49 lib/libboost_filesystem.a
lrwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_system.so.1.52.0 -> libboost_system.so
-rwxr-xr-x root/root 39605 2013-07-16 14:49 lib/libboost_chrono.so
-rwxr-xr-x root/root 115688 2013-07-16 14:49 lib/libboost_filesystem.so
lrwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_thread.so.1.52.0 -> libboost_thread.so
lrwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_chrono.so.1.52.0 -> libboost_chrono.so
rw-rr- root/root 32066 2013-07-16 14:49 lib/libboost_system.a
-rwxr-xr-x root/root 189003 2013-07-16 14:49 lib/libboost_thread.so
-rwxr-xr-x root/root 18334 2013-07-16 14:49 lib/libboost_system.so
lrwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_date_time.so.1.52.0 -> libboost_date_time.so
lrwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_filesystem.so.1.52.0 -> libboost_filesystem.so
rw-rr- root/root 119762 2013-07-16 14:49 lib/libboost_chrono.a
-rwxr-xr-x root/root 93746 2013-07-16 14:49 lib/libboost_date_time.so
rw-rr- root/root 322752 2013-07-16 14:49 lib/libboost_thread.a

but when I subsequently pull the artifact as a dependency elsewhere, the untar turns the symbolic links into zero-length files (still on CentOS 6.3 - same machine even).

$ ls util/build/dependency/boost/lib
rw-rr- root/root 135948 2013-07-16 14:49 lib/libboost_date_time.a
rw-rr- root/root 225978 2013-07-16 14:49 lib/libboost_filesystem.a
-rwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_system.so.1.52.0
-rwxr-xr-x root/root 39605 2013-07-16 14:49 lib/libboost_chrono.so
-rwxr-xr-x root/root 115688 2013-07-16 14:49 lib/libboost_filesystem.so
-rwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_thread.so.1.52.0
-rwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_chrono.so.1.52.0
rw-rr- root/root 32066 2013-07-16 14:49 lib/libboost_system.a
-rwxr-xr-x root/root 189003 2013-07-16 14:49 lib/libboost_thread.so
-rwxr-xr-x root/root 18334 2013-07-16 14:49 lib/libboost_system.so
-rwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_date_time.so.1.52.0
-rwxrwxrwx root/root 0 2013-07-16 15:00 lib/libboost_filesystem.so.1.52.0
rw-rr- root/root 119762 2013-07-16 14:49 lib/libboost_chrono.a
-rwxr-xr-x root/root 93746 2013-07-16 14:49 lib/libboost_date_time.so
rw-rr- root/root 322752 2013-07-16 14:49 lib/libboost_thread.a

Need to either have the dependency untar preserve the symbolic links contained within, or else need to be able to specify to Tar that it should dereference the links before storing...

S

 Comments   
Comment by Brian Krische [ 03/Apr/15 ]

I noticed that symlinks do not get preserved when creating a tarball with the Tar task as well. I'm using Gradle 2.3.

Comment by Paul McNamee [ 22/Jun/15 ]

This is a showstopper for us as we are trying to transition to Nexus. Our Mac And Linux archives have symbolic links.

The links are in the archive because we zip from a different process, not Gradle. The links are just not preserved when extracted.

I should also note, we are unzipping, not untarring, but zip/unzip has the same issue.

Comment by Gareth Bowles [ 04/Jul/16 ]

Note also that if you use a Tar or Zip type task to create an archive from a set of files including symlinks, the links are expanded into copies of the linked files.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Brad Moylan [ 15/Nov/16 ]

I am not the original reporter but this is still a bug

Comment by Eric Wendelin [ 03/Feb/17 ]

Migrated to https://github.com/gradle/gradle/issues/1321. I have marked this as help-wanted to denote that we will not likely have capacity to fix this in the near term but are happy to entertain a PR.

Generated at Wed Jun 30 12:33:03 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.