home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0146.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.9 KB
  1. From:  Dominic Dunlop <domo@tsa.co.uk>
  2.  
  3. [Moderator: please cross-post to comp.unix.wizards -- or let me know that
  4. you won't cross-post to unmoderated groups]
  5.  
  6. [I prefer not to cross post, but I sometimes do so if the number of
  7. newsgroups is small, the subject matter is appropriate, and especially
  8. if there's a Followup-To.  -mod]
  9.  
  10. In article <1990Jul23.171022.17798@phri.nyu.edu> roy@alanine.phri.nyu.edu
  11. (Roy Smith) writes:
  12. >The SunOS-3.5.2 man page for read(2) says:
  13. >
  14. >    On objects capable of seeking, the read starts at a position
  15. >    given by the pointer associated with d (see lseek(2)).  Upon
  16. >    return from read, the pointer is incremented by  the  number
  17. >    of bytes actually read.
  18. >
  19. Ah.  Isn't this interesting?  Here's what POSIX.1 (ANSI/IEEE Std.
  20. 1003.1:1988) has to say:
  21.  
  22.     On a regular file or other file capable of seeking, read() shall
  23.     start at a position in the file given by the file offset associated
  24.     with fildes.  Before successful return from read(), the file
  25.     offset shall be incremented by the number of bytes actually read.
  26.  
  27. >Now, if you are reading from a raw disk partition (say /dev/rxy0a) and get
  28. >a read error (because, for example, there is a bad block on the disk),
  29. >where should the pointer be after the read(2) call returns?  It turns out
  30. >that, at least for SunOS-3.5.2, the pointer is incremented, as if the bytes
  31. >in the bad block had actually been read.  I would consider this incorrect
  32. >behavior.  Do you agree?
  33. >
  34. Looking at the tighter and arguably sneakier wording of the standard,
  35. it appears that all bets are off as to the value of the file offset
  36. after an error.  Sure enough, the rationale says:
  37.  
  38.     The standard does not specify the value of the file offset after an
  39.     error is returned; there are too many cases.  For programming
  40.     errors, such as [EBADF], the concept is meaningless since no file
  41.     is involved.  For errors that are detected immediately, such as
  42.     [EAGAIN], clearly the pointer should not change.  After an
  43.     interrupt or hardware error, however, an updated value would be
  44.     very useful, and this is the behavior of many implementations.
  45.  
  46.     References to actions taken on an ``unrecoverable error'' have been
  47.     removed [from the standard].  It is considered beyond the scope of
  48.     this standard to describe what happens in the case of hardware
  49.     errors.
  50.  
  51. So, you'll be nonplussed to learn that SunOS' behaviour, which I agree is
  52. less useful than it could be, is POSIX-conformant.
  53.  
  54. >[Description of writing program which repeatedly seeked back to start of
  55. >failing blocks, and so eventually recovered slightly soft errors deleted.]
  56.  
  57. Should Sun wish to modify their drivers so that the file pointer points to
  58. the start of a failing block after an error, that behaviour too would be
  59. POSIX conformant.   You can't legislate for everything...
  60.  
  61. >"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
  62.  
  63. Wouldn't be POSIX either...
  64. -- 
  65. Dominic Dunlop
  66.  
  67. Volume-Number: Volume 20, Number 144
  68.  
  69.