Re: [Bug-tar] tar: ./anywhere/anydir/: Directory renamed before its status could be extracted <-- version 1.13.25 RedHat based dist

[Paul Eggert]

Filipe Vinci Dos Santos <address@hidden> writes:

> tar: ./long/convoluted/install/path/destination/dir/: Directory renamed 
> before its status could be extracted

This message is supposed to occur only when your tar file contains
dangerous symbolic links (e.g., symlinks to /etc, or symlinks to "..").
Normally tar attempts to extract these symlinks after all other work
is done, but this can collide with another thing that tar wants to
do "at the end", namely chmod/chown/etc the directories that are parents
of other files that it extracts, and which need to have their metadata
updated after all their children are extracted.  It's the latter step
that is printing that message.

Possibly your tar image has a tricky sequence of symlinks and
directories that look as though someone is trying to break into
your system by fooling "tar".

Another possibility is that some other process is modifying your
filesystem while you are extracting into it.

(Another possibility is that it's a bug in "tar".  :-)

> Is this a known bug ?

Not that I know of.

> Anyone has a quick and easy fix, please ?

The --absolute-names option should work around any problem here.
However, this also disables some important security checking, so don't
use it unless you trust the source of the tar image.
 
> I looked at alpha.gnu.org, gnu/tar seems to have a lot of bit-action, but, 
> can normal people who are *not* developers just compile one of those 
> versions and run with it ?

Yes, you should be able to build recent tar-alpha versions out of the box.

> The only "strange" thing in the setup I am doing this 
> is that I am extracting from an iso9660 image file mounted using the loop 
> option to a umsdos FAT32 filesystem. Who knows, maybe tar does not like 
> UMSDOS, but IMHO it should be transparent to it what kind of filesystem 
> it's reading/writing from/to.

Possibly umsdos is not reporting st_dev and st_ino correctly to tar,
when tar issues the 'stat' system call on an umsdos directory.  That
would explain the problem.  (It would also suggest that you have
a serious problem with umsdos, but that's a different matter.)

You can test this theory (and the other theories mentioned above) by
running strace on tar, and looking at what the stat calls are
returnning.