Tar and untar losing symbolic links

Old Forum Archive
1

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-r--r-- root/root
  135948 2013-07-16 14:49 lib/libboost_date_time.a
-rw-r--r-- 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-r--r-- 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-r--r-- 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-r--r-- 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-r--r-- root/root
  135948 2013-07-16 14:49 lib/libboost_date_time.a
-rw-r--r-- 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-r--r-- 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-r--r-- 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-r--r-- 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

2

I’ve raised this problem as GRADLE-2844.

Would you be interested in contributing a fix?

3

Hi, I am facing the same problem. My workaround is

task unpackFooLinux(type: Exec) {
 inputs.files configurations.testRuntime.files.find {it.name.contains(fooPackage)}
 outputs.dir fooBuildDir
   executable 'tar'
 args(['xzf', configurations.testRuntime.files.find {it.name.contains(fooPackage)}.absolutePath])
 workingDir fooBuildDir
    doFirst {
  fooBuildDir.mkdirs()
 }
}

The code I wrote first is much nicer

task unpackFooWin(type: Copy) {
 from configurations.testRuntime.files.findAll {it.name.contains(fooPackage)}.collect { file ->
  if(file.name.endsWith('.zip'))
   zipTree(file)
  else if(file.name.endsWith('.tar.gz'))
   tarTree(resources.gzip(file))
 }
 into fooBuildDir
}
4

In spite of the plugin I’m working on, Java/Groovy are not my primary languages so I’m still feeling my way through the code trying to figure it out. I’m primarily C/C++. If it is still a problem when I finally get to the point of figuring it out and developing a fix, I would, of course, submit it.

5

If you do get the chance to dig in, you’ll need to make changes @ https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/api/internal/file/archive/TarCopyAction.java#L66

6

I did a first try on untaring. https://github.com/gradle/gradle/pull/182