Bob Proulx <[email protected]> wrote:

> That does seem odd to me.  Compare these two cases:
>
>   $ date -R > afile
>   $ ls -l afile
>   -rw-rw-r-- 1 bob bob 32 2010-10-09 01:07 afile
>   $ tar cvvf x.tar afile afile afile
>   -rw-rw-r-- bob/bob          32 2010-10-09 01:07 afile
>   -rw-rw-r-- bob/bob          32 2010-10-09 01:07 afile
>   -rw-rw-r-- bob/bob          32 2010-10-09 01:07 afile
>
> All three copies of the file are in the archive.  Now let's add a hard
> link to the file.

This case is not really different as SUSv2 permitted tar to include data even 
for hardlinks on files.

>   $ ln afile hlink
>   $ ls -l afile
>   -rw-rw-r-- 2 bob bob 32 2010-10-09 01:07 afile
>
> Then try the tar archive creation again.
>
>   $ tar cvvf x.tar afile afile afile
>   -rw-rw-r-- bob/bob          32 2010-10-09 01:07 afile
>   hrw-rw-r-- bob/bob           0 2010-10-09 01:07 afile link to afile
>   hrw-rw-r-- bob/bob           0 2010-10-09 01:07 afile link to afile
>
> Why did having afile hardlinked to another file change the behavior of
> tar?  Why did having afile's hardlink count greater than 1 cause tar
> to think that afile was a hardlink to afile?  It is reporting it as
> being a hard link to itself.  That doesn't look right.  Why didn't it
> just archive the file again as it did in the first case?

For many tar implementation, this changes the behavior during extract.

> Of course when untar'ing the archive the file is restored okay.  So
> this seems like a completely academic question of why did tar behave
> differently and show a cosmetic difference in behavior trace output.
> As opposed to actually producing a result on disk which is incorrect.

Extracting the second archive only works correctly if the implementors of this
tar variant listened to the security warning related to hard links I put 
out in summer 2003.

The other tar implementations will remove the existing plain file while 
preparing to create the hardlink.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]                (uni)  
       [email protected] (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Reply via email to