[comp.lang.c] Misinformation on lseek

g-rh@cca.CCA.COM (Richard Harter) (09/06/87)

In article <4469@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes:

>Date and time are easily convertible under any OS; but how do you implement
>a byte-oriented lseek() under VMS?  VM/CMS on an IBM?  (Both use fixed 80-byte
>records for text files -- NOT byte streams! -- and other record formats for
>non-text files.)

(1) The default file format under VMS is variable length records with a
two byte count field.  VM/CMS uses 80 byte records as a default for everything
unless otherwise specified.

(2) Both systems offer a variety of file formats; the user may select the
file format type.  Both offer raw blocking, i.e files with a fixed physical
record size with no internal formatting.  [Effectively this is the only
thing that UNIX supplies.]

(3) There is no particular problem about writing an lseek for these
operating systems -- VAX/VMS supplies lseek.  The problem comes when one
tries to read (or write) from a location which is not a record boundary.
In general this loses [note that 'lose' only has one 'o', a pet peeve of
mine].

In general, one's I/O utilities must match the device or file type that
they are dealing with.  Lseek, read, and write are appropriate tools for
raw unformatted files.  Reasonable operating systems which provide 
formatted files also provide unformatted files and the means for changing
file formats.

There is no reason for not standardizing lseek, read, and write for
file types where they are applicable and no good reason to use them
for file types where they are not.  Open and create, on the other hand,
are not standardizable -- one of the functions of open, in a system
with multiple file types, is to specify the file attributes.

Apologies for any further misinformation inadvertently contained in
the above.  I stand corrected in advance.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.

guy%gorodish@Sun.COM (Guy Harris) (09/07/87)

> (2) Both systems offer a variety of file formats; the user may select the
> file format type.  Both offer raw blocking, i.e files with a fixed physical
> record size with no internal formatting.  [Effectively this is the only
> thing that UNIX supplies.]

More correctly, this is the only thing the UNIX *kernel* supplies (if you don't
count e.g.  the terminal driver, which returns lines terminated by NL when in
cooked mode).  The UNIX standard I/O library routine supplies variable-length
lines terminated with NL, and fixed-length records ("fread", "fwrite").  The
record format is not stored in the file system in any fashion.

The VMS *kernel*, to the best of my knowledge, only supplies raw blocking (QIOs
to read and write blocks); the various record formats are provided by RMS.  The
file system permits packages such as RMS to store file attributes in the file's
header.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

peter@sugar.UUCP (09/11/87)

See "Software Tools" by Kernighan and Plauger.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
--                 'U`  <-- Public domain wolf.