I found out a possible bug (well, either that or I'm just stupid) in tar, while trying to tar/untar my /usr directory for defragmentation purposes: I do: # cd / # mkdir test # tar czvf test/usr.tar.gz usr/ --preserve # cd test/ # tar zxvf usr.tar.gz --preserve Now, I should have a /test/usr directory, identical to my /usr, right? Wrong! Tar has taken the liberty to break all my absolute-path symlinks. For example, this file: lrwxrwxrwx 1 root root 23 Ιαν 24 15:10 xpak -> ../lib/portage/bin/xpak in /usr/bin now becomes: ---------- 1 root root 23 Ιαν 24 15:10 xpak i.e. a regular file, NOT a symlink. If I replace "tar zxvf usr.tar.gz --preserve" with "gunzip usr.tar.gz; tar xvf usr.tar --preserve", the problem just solves itself. From what I've seen in Google search, this appears to be a bug with tar and gzip, and others have also had this problem. I'm running tar 1.15.1 on a ReiserFS filesystem, kernel 2.6.15-gentoo-r1.
did you interrupt the extraction process ? xpak will be created as a file at first, but once tar finishes, the result will be a symlink ... rm -rf /root/tar-test mkdir /root/tar-test cd /root/tar-test tar czf foo.tar.gz /usr/bin /usr/lib/portage/ --preserve tar xzf foo.tar.gz --preserve & while true ; do [ -e usr/bin/xpak ] && ls -l usr/bin/xpak ; done ... ---------- 1 root root 0 Mar 8 23:05 usr/bin/xpak ---------- 1 root root 0 Mar 8 23:05 usr/bin/xpak ---------- 1 root root 0 Mar 8 23:05 usr/bin/xpak lrwxrwxrwx 1 root root 23 Mar 8 23:05 usr/bin/xpak -> ../lib/portage/bin/xpak lrwxrwxrwx 1 root root 23 Mar 8 23:05 usr/bin/xpak -> ../lib/portage/bin/xpak lrwxrwxrwx 1 root root 23 Mar 8 23:05 usr/bin/xpak -> ../lib/portage/bin/xpak [1]+ Done tar xzf foo.tar.gz --preserve
I can't repro this bug either. I did mkdir test cd test tar czvf foo.tar.gz usr/bin usr/lib --preserve tar zxf foo.tar.gz ls -l usr/bin/xpak And the output was: usr/bin/xpak -> ../lib/portage/bin/xpak using tar version 1.15.1-r1
(In reply to comment #1) > did you interrupt the extraction process ? xpak will be created as a file at > first, but once tar finishes, the result will be a symlink ... No, I haven't interrupted the process. I've reproduced the bug many times. It only happens with relative (../) symlinks, and only when using gzip, as described above. - When doing "tar zxf ..." relative symlinks are broken. - When doing "gunzip ...; tar xf ..." relative symlinks work. They are created as symlinks (not normal files) from the begining. At first, they are broken symlinks of course but, once tar finishes, they are OK. I understand this may be a problem specific to certain tar and gzip version(s). The ones I tested with are: app-arch/tar-1.15.1 app-arch/gzip-1.3.5-r8
OK, tested again and problem doesn't happen with new app-arch/tar-1.15.1-r1. I'm leaving the bug open, but for me is resolved.
