Re: [Bug-tar] TAR creates hard links or duplicated files in sidearchive when using -T option

[Marek Kielar]

Hi,

I'd like to make an input to this thread.

I have always seen archiving as cutting out a part of an existing file system. 
The archive is by itself a separate (even if virtual) file system - a single 
tree. When viewed this way, some behaviors seem to me quite intuitive.

When a file is given twice through the same hard link (whether explicitly or 
implicitly through recursion) - that is, when it would be effectively the same 
hard link in the "virtual" file system of the archive - I would rather expect 
it to be skipped the second time with a warning emitted, as I don't see a 
real-life-file-system example that would need the file included through the 
same hard link a second time by any means.

I would expect a hard link to be included only when the same file was listed 
again but through an additional hard link with some other name, and that also 
included only once, if given multiple times on the command line.

This would probably call for remembering the "file system" tree during 
operating on the archive.

As for the cases when programs expect behavior that is actually not possible in 
real life file systems: any behavior might be desirable then - they have 
artificial premises and they probably expect artificial behavior - and until 
all of such behavior is supported there will be dissatisfaction among the 
programs' users.

When a file is listed twice, some might expect the file's contents included 
twice, since "what you want is what you get", some might expect a hard link to 
"optimize" the disk space used by the archive but not losing the information 
about additional mentioning on the command line, some might expect it to not be 
included at all the second time, and some might even want the Solaris solution. 
Some might expect to be able to command the archiver to do one with one file 
and the other with another file or even the same file once again - once the 
problem gets artificial there are no "reasonable, real-life" bounds.

The Solaris behavior is "irrational" as it's irrelevant to the archive, but 
it's still an acceptable artificial solution to a problem with artificial 
premise under some circumstances - and it actually is consistent, but regarding 
the file system it is created on.

Best regards,
Marek Kielar


Dnia 5 listopada 2012 17:42 Paul Eggert <address@hidden> napisał(a):

> On 11/05/2012 06:56 AM, Joerg Schilling wrote:
> > I was talking about the relation to a tar archive, not about the correct 
> > interpretation inside a file system.
> 
> Tar archives don't have link counts;
> file systems do, so I'm puzzled as to
> why link counts are relevant for tar
> archives.
> 
> > The indication for the existence of an additional
> > hard link to a file is a link count > 1.
> 
> Yes, that's true for file systems.  But tar
> archives don't have link counts, so this rule
> does not apply to them.
> 
> Let's contrast Solaris tar ('tar' below)
> with GNU tar ('gtar'):
> 
> $ touch a b
> $ ln a alink
> $ tar cf tar a a b b
> $ tar tvf tar
> tar: blocksize = 6
> -rw-rw-r-- 5823/30       0 Nov  5 08:39 2012 a
> -rw-rw-r-- 5823/30       0 Nov  5 08:39 2012 a linked to a
> -rw-rw-r-- 5823/30       0 Nov  5 08:39 2012 b
> -rw-rw-r-- 5823/30       0 Nov  5 08:39 2012 b
> $ gtar cf tar a a b b
> $ gtar tvf tar
> -rw-rw-r-- eggert/faculty    0 2012-11-05 08:39 a
> hrw-rw-r-- eggert/faculty    0 2012-11-05 08:39 a link to a
> -rw-rw-r-- eggert/faculty    0 2012-11-05 08:39 b
> hrw-rw-r-- eggert/faculty    0 2012-11-05 08:39 b link to b
> 
> Solaris tar treats A different from B, because there's
> some other hard link in the file system that happens to
> be the same as A, even though this other hard link has
> nothing to do with tar's operands or operation.
> 
> GNU tar treats A and B consistently.
> 
>