Date: Sun, 12 Apr 1998 10:41:00 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Message-ID: <199804121641.KAA11609@narnia.plutotech.com> In-Reply-To: <199804070732.XAA28712@revolution.3-cities.com> <199804120721.BAA09794@narnia.plutotech.com> <19980412124340.50537@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <19980412124340.50537@uriah.heep.sax.de> you wrote: > As Justin T. Gibbs wrote: > >> > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. >> >> ENOSPC is the correct error code. > > Where did you get this from? All descriptions for ENOSPC i could find > (our own man page, as well as ``The single UNIX specification'' on > http://www.rdg.opengroup.org/onlinepubs/ -- i don't have access to the > appropriate Posix docs) make it very explicit that ENOSPC is only > related to regular files and directories. I'm not an opengroup member, so I can't read their pages. My understanding is that BSDOS also returns ENOSPC in this scenario. >> It is even documented in dump that >> it's lack of handling ENOSPC as EOT is a bug. > > No. I can't seem to find it. The only mention of ENOSPC is: > > /* > * fixme: Pyramids running OSx return ENOSPC > * at EOT on 1/2 inch drives. > */ > > ...which rather sounds like an idiosyncrasy on Pyramid's OS than the > admission of a bug in dump. Regardless of the definition of ENOSPC, dump must handle it. I can just as easily dump to a regular file as a special file. > How do you `fix' all the other programs inside and outside our tree? > (Start with GNUtar's multi-volume handling for an example.) GNUtar's multi-volume handling deals with ENOSPC just fine: /* We're multivol Panic if we didn't get the right kind of response */ /* ENXIO is for the UNIX PC */ if (err < 0 && errno != ENOSPC && errno != EIO && errno != ENXIO) writeerror (err); > I think this violates the traditional behaviour. Alas, the existing > docs are not fully clear on this, and allow both interpretations. Our > own write(2) man page is rather thin on this. The UNXI spec is a > little more verbose: > > If a write() requests that more bytes be written than there is > room for (for example, the ulimit or the physical end of a > medium), only as many bytes as there is room for will be > written. For example, suppose there is space for 20 bytes more > in a file before reaching a limit. A write of 512 bytes will > return 20. The next write of a non-zero number of bytes will > give a failure return (except as noted below) and the > implementation will generate a SIGXFSZ signal for the thread. > > It only tells about ``the next write of a non-zero number'', and this > entire man page doesn't mention special files at all. :( Again, i'm > just arguing to follow what's IMHO the traditional behaviour, so > software relying on it would work. (And i don't see that this > traditional behaviour would be in violent conflict with these specs.) Perhaps special files are not mentioned because they should behave the same as ordinary files??? Isn't that supposed to be the UNIX way? It seems rather clear to me from the above description that a non-zero length write that doesn't write a single byte for lack of space is supposed to return an error. The only thing you've argued against is the use of ENOSPC for that error. I think it's bogus to limit ENOSPC's definition to just ordinary files as "Device out of space" makes all too much sense for this situation. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804121641.KAA11609>