Re: tar option suggestion

[Jim Hefferon]

Paul,

You replied to me:
   > From: Jim Hefferon <address@hidden>
   > Date: Thu, 7 Mar 2002 15:24:51 GMT
   > 
   > Please, may I request of you a flag that allows us to turn off this
   > padding behavior?

   OK, but doesn't the --blocking-factor=1 option do that already?
   If not, can you please explain with an example?


Thanks for your reply.  Please forgive me if I have got it wrong.  There is a
lot in the documentation on blocking, but for instance here is one. 

  When writing to tapes, tar writes the contents of the archive in chunks 
  known as records. To change the default blocking factor, use the
  --blocking-factor=512-size (-b 512-size) option. Each record will 
  then be composed of 512-size blocks. (Each tar block is 512 bytes. See 
  section The Standard Format.) Each file written to the archive uses at 
  least one full record. As a result, using a larger record size can result 
  in more wasted space  for small files. On the other hand, a larger record 
  size can often be read and written much more efficiently. 

Doesn't mean that (after compression, which is when I am interested)
that all files are padded out to a multiple of 512 bytes (even 1*512)?

I see this further down; I read it to say the same thing.  Am I misreading it? 

  --blocking-factor=number 
  -b number 
       Specifies the blocking factor of an archive. Can be used with any 
  operation, but is usually not necessary with --list (-t). 

  Device blocking 

  -b blocks 
  --blocking-factor=blocks 
       Set record size to blocks * 512 bytes. This option is used to specify 
       a blocking factor for the archive. When reading or writing the archive,
       tar, will do reads and writes of the archive in records of block*512 
       bytes. This is true even when the archive is compressed. 

(I am getting these from 
  http://www.gnu.org/manual/tar/html_chapter/tar_9.html#SEC125
.)  The difficulty is that our users (who are often not experienced systems
folks) are troubled by the ``trailing garbage'' that gzip reports.  The 
same documentation mentions this a few lines further down.

  gzip will complain about trailing garbage if asked to uncompress a 
  compressed archive on tape, there is an option to turn the message off,
  but it breaks the regularity of simply having to use `prog -d' for 
  decompression. It would be nice if gzip was silently ignoring any number
  of trailing zeros. I'll ask Jean-loup Gailly, by sending a copy of this 
  message to him. 

(We are of course not writing to tape, we are writing to a pipe, but it
is nonetheless blocked and gzip has the same reaction.)

I can give you an example of a CTAN mirror that is sending .tar.gz files that
result in this `trailing garbage' warning.  I just got

   ftp://ibiblio.org/pub/packages/TeX/macros/texinfo.tar.gz

and it gave me that warning.  (I mentioned that I backed off to a prior
version of tar to avoid it, so my site doesn't give it anymore.)  I'm sorry;
I don't know what their blocking factor is.  I expect that it is the default.

I see that this is something gunzip should handle, but my situation is that 
I have thousands of users with gzip's that don't handle it, and perhaps the 
slightly uglier expedient of an obscure tar option would alleviate the 
problem, until the gzip folks' changes can work their way into general 
circulation?

That is, is it possible to have an option that eliminates blocking, especially
after the compression?   That'd be a help.

Thanks for your reply; sorry to ask something of you.  We obviously use
your progam many times every day and appreciate your work.

Jim