Re: hard link pointing to itself?

On 2/17/24 18:14, Greg 'groggy' Lehey wrote:
> On Saturday, 17 February 2024 at  8:28:53 -0700, Gary Aitken wrote:
>> running 13.2-release, created a tar archive, went to extract on
>> another 13.2-release system, and got several messages of the form:
>> 
>> $ tar xf tmp.tar path-to-file/filename.jpg: Skipping hardlink
>> pointing to itself: path-to-file/filename.jpg: File exists
> 
> Fascinating.  I'm rearranging the rest of your message to hopefully 
> explain things better.

<snip>

> Yes, it's confusing.  It confused me too.  I went and took a look at 
> the sources (in this case the file 
> /usr/src/contrib/libarchive/libarchive/archive_write_disk_posix.c), 
> and found what's going on--I think.  The hard links aren't in the
> file system, they're in the tar archive.  And one of the more
> obscure things about a tar archive is that it needs to keep track of
> files with multiple links (names).  It stores the file under one
> name, and if there are any more, it creates a reference to the same
> file.  It seems that this somewhat confusing message is saying that
> it discovered some inconsistency that it (and the author of
> libarchive) wasn't expecting.  From the source to
> archive_write_disk_header() (round line 563):
> 
> /* * Extract this entry to disk. * * TODO: Validate hardlinks.
> According to the standards, we're * supposed to check each extracted
> hardlink and squawk if it refers * to a file that we didn't restore.
> I'm not entirely convinced this * is a good idea, but more
> importantly: Is there any way to validate * hardlinks without keeping
> a complete list of filenames from the * entire archive?? Ugh. */
> 
> Without going into too much detail, this looks like some kind of
> bug. I've tried to think of a number of scenarios, but I can't at
> the moment.

bummer :-(
Thanks for the deep dive.  I understand the difference between hard
and symlinks, and the inode # and count.  I forgot about the different
hard links being able to have different names, which may be my
problem somehow.

>  It would be interesting to know what you were trying to
> do. Does it happen when you try to extract the entire archive to an
> empty hierarchy?  Does this file have multiple links?

Yes, the files have multiple links; count is 2.

Ah... thank you for the hints, found them.
Problem was:

   file system looked like:
     /home/me/A/B/C/D/file.jpg
                 /X/file.jpg
   tarball created:
     cd /home/me/A/B/C
     tar cf foo.tar D
   so the other file was not in the tarball.

located by doing:
$ ls -il foo.jpg          # get inode # of bad file
$ df | grep home          # make sure /home is a mount point
$ cd /home
$ find -xX . -type f | xargs -L 1 ls -il | grep inode#

> Another thing that might be interesting would be to try GNU tar 
> (gtar, in the ports).  It might accept the archive, or it might 
> produce a different error result.

Thanks, may try that.

> My guess is that there might be two different issues here.  The 
> message you show is a warning, though it does mean that the file 
> doesn't get restored.  Was there another message at the end?

The job was backgrounded, but terminated after a few errors.
As far as I know no other message.

So I guess a question now is, is there a way to get tar to
somehow ignore the inode count / force it to 1 when tar creates
the tarball?  Or maybe just tell tar to ignore hard links when
extracting.  Too late read the tar manpage with all those args
and work on further tonight; will poke at it tomorrow.

Thanks again,

Gary

> Greg -- When replying to this message, please copy the original
> recipients. If you don't, I may ignore the reply or reply to the
> original recipients. For more information, see
> http://www.lemis.com/questions.html Sent from my desktop computer. 
> See complete headers for address and phone numbers. This message is
> digitally signed.  If your Microsoft mail program reports problems,
> please read http://lemis.com/broken-MUA.php