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 <[email protected]> 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. > >
