Location of seek pointer after read error?

[Dominic Dunlop]

From:  Dominic Dunlop <domo at tsa.co.uk>

[Moderator: please cross-post to comp.unix.wizards -- or let me know that
you won't cross-post to unmoderated groups]

[I prefer not to cross post, but I sometimes do so if the number of
newsgroups is small, the subject matter is appropriate, and especially
if there's a Followup-To.  -mod]

In article <1990Jul23.171022.17798 at phri.nyu.edu> roy at alanine.phri.nyu.edu
(Roy Smith) writes:
>The SunOS-3.5.2 man page for read(2) says:
>
>	On objects capable of seeking, the read starts at a position
>	given by the pointer associated with d (see lseek(2)).  Upon
>	return from read, the pointer is incremented by  the  number
>	of bytes actually read.
>
Ah.  Isn't this interesting?  Here's what POSIX.1 (ANSI/IEEE Std.
1003.1:1988) has to say:

	On a regular file or other file capable of seeking, read() shall
	start at a position in the file given by the file offset associated
	with fildes.  Before successful return from read(), the file
	offset shall be incremented by the number of bytes actually read.

>Now, if you are reading from a raw disk partition (say /dev/rxy0a) and get
>a read error (because, for example, there is a bad block on the disk),
>where should the pointer be after the read(2) call returns?  It turns out
>that, at least for SunOS-3.5.2, the pointer is incremented, as if the bytes
>in the bad block had actually been read.  I would consider this incorrect
>behavior.  Do you agree?
>
Looking at the tighter and arguably sneakier wording of the standard,
it appears that all bets are off as to the value of the file offset
after an error.  Sure enough, the rationale says:

	The standard does not specify the value of the file offset after an
	error is returned; there are too many cases.  For programming
	errors, such as [EBADF], the concept is meaningless since no file
	is involved.  For errors that are detected immediately, such as
	[EAGAIN], clearly the pointer should not change.  After an
	interrupt or hardware error, however, an updated value would be
	very useful, and this is the behavior of many implementations.

	References to actions taken on an ``unrecoverable error'' have been
	removed [from the standard].  It is considered beyond the scope of
	this standard to describe what happens in the case of hardware
	errors.

So, you'll be nonplussed to learn that SunOS' behaviour, which I agree is
less useful than it could be, is POSIX-conformant.

>[Description of writing program which repeatedly seeked back to start of
>failing blocks, and so eventually recovered slightly soft errors deleted.]

Should Sun wish to modify their drivers so that the file pointer points to
the start of a failing block after an error, that behaviour too would be
POSIX conformant.   You can't legislate for everything...

>"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

Wouldn't be POSIX either...
-- 
Dominic Dunlop

Volume-Number: Volume 20, Number 144