Re: Issues with lseek(2) on a block device

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 25 Feb 2024 04:16:03 -0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <ureeu3$m61$1%serpens.de@localhost>

  | lseek() doesn't move the tape. But the open() or close() may trigger
  | tape operations like loading or winding. Special files are special.

The issue is more the return value from lseek() - POSIX requires that
lseek(fd, 0, SEEK_END) return the "size of the file" on any device
which supports seeking (ie: not ttys, pipes, etc).   A tape that
supports seeking would be one of those, so somehow, lseek() as it
is worded now, would be required to return "the size of the file"
whatever that actually means for a tape.

I have submitted a bug report (just earlier today) to get that fixed,
but it will be some time before anything happens (it is too late now
for the next version of the standard, which is currently in its final
stages).

kre

ps: as a semi-related anecdote, the first system I ever personally
installed any unix version onto (way back in the mid 70's) booted from
a reel to reel (1/2" I think) tape - and by booted, I mean ran with its
filesystems (or filesystem, everything was in one) on the tape (read only,
naturally).

It wasn't fast, but it worked...    It worked even better once the
filesystem was copied to a disc!   (The issue was that, at the time,
there was no available unix code that allowed booting from a disc,
or not one of the kind that we had - whereas the hardware made booting
from a tape absolutely trivial.   All in the days before any kind of
intelligent firmware console was available - booting required entering
the boot program to ram via a front panel - "put X in location Y" ...)