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: [email protected] Phone: 630 979 8031
