Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!think.com!snorkelwacker.mit.edu!shelby!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: Finding tape block size
Message-ID: <15222@smoke.brl.mil>
Date: 16 Feb 91 05:34:24 GMT
References: <1991Feb12.224353.6514@gjetor.geac.COM>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 17

In article <1991Feb12.224353.6514@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes:
>... if there's a way to determine exactly what block size was used when the
>tape was written, or even if this is a major requirement (should I even be
>worrying about it or not?).

Assuming your tape subsystem conforms to long-established UNIX practice,
if the read() system call specifies a read count less than the actual
block size when reading the "raw tape" device (which is the usual one),
you should get an I/O error since data will be lost.  (If you're trying
to read a "tar" or "cpio" archive, and data ever does get silently lost,
you should see archive checksum comparison errors.)  For read counts
in excess of the block size, read() returns the actual amount of data
read, not the requested size.  Therefore the usual practice is to try to
read using an over-generous allocation for the input buffer, which should
not introduce any significant amount of inefficiency.

If you have an oddball device driver or hardware, you may be out of luck.