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
