Re: [Bug-tar] record size = x blocks?

[Peter Fales]

There are some platforms where this message seems to occur conistently.
Specifically, my message of March described "make check" failures of test
67 due to this message on Mac OS/X and HP/UX 10.20.    Nelson H. F. Beebe's
message on March 7 mentioned six platforms where he was also  getting 
failures of test 67.


On Thu, Mar 12, 2009 at 10:15:03AM -0700, Tim Kientzle wrote:
> Peter Fales wrote:
> >I see that a couple of people have asked about these messages, but I
> >haven't seen a response.  Can someone explain what triggers these
> >messages and whether it indicates some sort of problem?
> 
> GNU tar 1.22 seems to look at the first read and use it to determine
> the "record size" for the remaining reads.  If this is different
> than what tar expected (the historical default and the one
> sanctioned by POSIX is 20 blocks or 10k), it prints an
> informational message to stderr.  This is sensible behavior
> when reading from tape drives, where the record size is a fundamental
> property of the stored archive.
> 
> I found it easy to reproduce using 'dd' (output edited for clarity):
> 
> $ gtar-1.22 --version
> tar (GNU tar) 1.22
> $ gtar-1.22 cf - . | dd bs=4k | gtar-1.22 -tvf - >/dev/null
> gtar-1.22: Record size = 8 blocks
> $ gtar-1.22 cf - . | dd bs=3k | gtar-1.22 -tvf - >/dev/null
> gtar-1.22: Record size = 6 blocks
> 
> It does not change the exit code, however.  I was unable
> to reproduce it using normal disk files and pipes without
> a tool such as 'dd':
> 
> $ gtar-1.22 cf - . | gtar-1.22 -tvf - >/dev/null
> (no output)
> $ gtar-1.22 zcf - . | gtar-1.22 ztvf - >/dev/null
> (no output)
> $ gtar-1.22 zcf - . | dd bs=3k | gtar-1.22 ztvf - >/dev/null
> (no output)
> 
> This last result surprised me until I remembered how GNU tar
> handles gzip decompression (it forks gzip in such a way that
> gzip is reading directly from the input source).
> 
> I haven't seen anyone mention what platform they were using;
> it's possible that some platforms have pipe behavior that
> prompts this message when it shouldn't occur.
> 
> Hope this helps,
> 
> Tim Kientzle

-- 
Peter Fales
Alcatel-Lucent
Member of Technical Staff
2000 Lucent Lane
Room: 1C-436
Naperville, IL 60566-7033
Email: address@hidden
Phone: 630 979 8031