|
From: | Juan PC |
Subject: | Re: [Bug-tar] Option -h of tar 1.26 is broken |
Date: | Wed, 16 Nov 2011 11:05:26 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 |
Hi Sergey, Thank you for your prompt reply. El 16/11/11 00:13, Sergey Poznyakoff escribió:
Juan PC<address@hidden> ha escrit:Option -h is not working in tar 1.26. When creating a tar archive, if the file a symlink points to (let us call it "the original file") appears after the symlink, then, the original file can not be individually extracted from the tar file. Here you have the proof (Linux distribution is Fedora 16):In this case tar does exactly what it is supposed to do: follows the symbolic link. Since the link points to another file already added to the archive, it is then converted to hard link [1]. If it's not what you want, use --hard-dereference together with -h: tar -cvzhf test.tgz --hard-dereference /etc/rc0.d/K15httpd /etc/rc.d/init.d/httpd Regards, Sergey [1] http://git.savannah.gnu.org/cgit/tar.git/commit/?id=37ddfb0b7eb41cc3f58bce686d389b1e965e9ccf
Therefore, I must assume that the behavior of the -h option has changed. This is the same test with tar 1.23 (and Fedora 14):
address@hidden ~]# tar cvzhf test.tgz /etc/rc.d/init.d/httpd /etc/rc0.d/K15httpd
tar: Removing leading `/' from member names /etc/rc.d/init.d/httpd /etc/rc0.d/K15httpd address@hidden ~]# tar xvzf test.tgz etc/rc.d/init.d/httpd etc/rc.d/init.d/httpdaddress@hidden ~]# tar cvzhf test.tgz /etc/rc0.d/K15httpd /etc/rc.d/init.d/httpd
tar: Removing leading `/' from member names /etc/rc0.d/K15httpd /etc/rc.d/init.d/httpd address@hidden ~]# tar xvzf test.tgz etc/rc.d/init.d/httpd etc/rc.d/init.d/httpd address@hidden ~]# tar tvzf test.tgz -rwxr-xr-x root/root 3316 2010-10-27 12:05 etc/rc0.d/K15httpd -rwxr-xr-x root/root 3316 2010-10-27 12:05 etc/rc.d/init.d/httpdProbably, the new behavior is the right one, but I was expected the old behavior, that is, that any symlink is removed and replaced with a copy of the file the symlink is pointing to (and this is also what I understand after reading the man page and info documentation of tar :(). Obviously, a tarball storing several copies of the same file will be bigger than a "regular" tarball which stores symlinks as such, but I also expect that.
Regards, Juan
[Prev in Thread] | Current Thread | [Next in Thread] |