bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tim Kientzle
Subject: Re: [Bug-tar] record size = x blocks?
Date: Thu, 12 Mar 2009 10:15:03 -0700
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]