Re: Possible tar bug when restoring symlinks in a chrooted environment

[Bob Proulx]

Tony Green wrote:
> I've come across what I *think* is a bug in the way GNU tar restores 
> symbolically linked files.

It certainly sounds troubling.  However, may I suggest that you make
this report to <address@hidden> instead of to bug-fileutils?  This is
the wrong list for tar problems.

However, I will make some comments here regardless, since here it is.

> The problem appears to relate to restoring symlinks that have absolute paths 
> when in a chrooted environment.

I have a chroot'd area handy and so tried your test case.  I was
unable to reproduce your problem.

> Specifically, I have had this problem when rebuilding my filesystem
> after booting from a rescue disc and mounting the real filesystems
> under /mnt.  After restoring from a tarball, symlinks that had
> absolute paths become empty files with null file permissions.

Hmm...  That makes me suspicous.  In the rescue environment are you
sure you are using the same versions of the commands as in the normal
environment?  Frequently rescue environments have smaller versions of
commands.  Perhaps your problem resides in a rescue version?  Is bzip2
available in the rescue environment?  Just a thought.  Something to
double check.

In general being a chroot'd environment will have no effect on tar.
It won't know it is in the chroot.  But the kernel is the previous
kernel that you chroot'd from and not the system to which you chroot'd
into.  Therefore your problem may be an issue with the rescue kernel.

> Commands used:
> Building the archive:
> tar --bzip2 -cX /tmp/backup-excludes --atime-preserve -p -f \
> /tmp/full-backup.tar.bz2 /*
> 
> Restoring:
> tar --bzip2 -xvf /tmp/full-backup.tar.bz2

If it is possible to reproduce this without any compression it would
be an important data point.  I personally would be suspicious of bzip2
in your rescue environment.

> As an example, the proper listing for /bin/vi from ls -al is:
> lrwxrwxrwx    1 root root  20 Feb  4 20:43 /bin/vi -> /etc/alternatives/vi*
> 
> If I restore from my backup with filesystems mounted as normal, this is 
> restored correctly. However, if I restore in the chrooted rescue environment, 
> the listing becomes:
> ---------- 1 root root 20 Feb  4 20:43 /bin/vi

Ew, the size is correct, so it is not an empty file.  Both it and the
symlink were 20 bytes long.

> This occurs every time and does not seem to be related to the
> filesystem type, as I have replicated it with ext2 and ReiserFS
> types.
> 
> Not something that 's a problem in normal day-to-day use, but just what you 
> don't need when you're trying to restore a broken system :-)

I think without more data it will be impossible for the tar
maintainers to further debug this problem.  You did a good job of
describing it.  But still probably the best someone could say is
"works for me" which is certainly not satisfying to the person such as
yourself who is seeing the problem.

I have two test cases that I can describe that work for me.  I have a
chroot area /sid with a complete copy of the os.  If I chroot there I
can definitely untar symlinks with no trouble.  I actually do that
routinely as part of general activity.  Secondly I can and have booted
KNOPPIX (cdrom standalone boot image, I highly recommend it,
http://www.knopper.net/knoppix/index-en.html) using it as a recovery
system and chrooted to the disk to recover files there.  Again, I am
able to untar files fine in that area.  "Works for me."

I am very suspicious that the problem resides in the particular rescue
environment you are using.  You might try another.  If you have the
bandwidth and capabilities to download and burn an ISO cdrom image
then I suggest that you try the KNOPPIX image I mentioned earlier.  I
believe you will find both that it is quite handy and well worth the
effort.  I do not believe the problem exists there.

Bob