Speed of seeks

[Peter da Silva]

> Wait a sec... A Seek() call on the Amiga HAS to read every sector.
> 
> Each sector on the amiga contains a (byte, word, long, whatever) indicating
> how much of the sector is used. So, if you want to read byte 600, you can't
> just go to the second record-- you have to go to the first, find out how
> much space it uses, go to the second, find out how much, etc.

If this is the case, and if it is also the case that the Amiga directories
don't contain the file names (what do they contain? a hash table?), then C=
Amiga has some serious redesigning to do before I or anybody I know actually
go out and buy this thing.

Incidentally, despite the poor design of the files a seek() does not have to
read every sector... a mistake often made by library writers is to try to
make seek offsets simple integers. According to the library, the argument
to an absolute seek() (lseek(fd, off, 0) or lseek(fd, off, 2)) only needs
to be the returned value from a tell() call: it may indeed be a magic cookie
like a sector/offset pair (and in fact "magic cookie" is the way it's described
in the manual). It is under RSX/11M and on the ATARI 800.

This error is not restricted to relative newcomers: there's an IBM mainframe
implementation of 'C' that copies all files into fixed record length files
when you open them just so you can use UNIX-like seeks. If you want to do
a UNIX-like seek, build UNIX-like files (either one long "record" or a bunch
of maximum length records) so your offset calculations work. It's not
meaningful to seek to an unknown depth in a text file or other weird file
anyway.

The Lattice 'C' runtime library on the IBM-PC has an obscure bug related to
this, by the way, so I'm not surprised they screwed up their Amiga library
too...
-- 
-- Peter da Silva
-- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076