(Fwd) Re: SCSI tape data loss

[Daniel Eischen]

On Wed, 27 Aug 2003, Daniel Eischen wrote:

> On Wed, 27 Aug 2003, Nate Lawson wrote:
> 
> > On Wed, 27 Aug 2003, Dan Langille wrote:
> > > On 27 Aug 2003 at 11:06, Nate Lawson wrote:
> > > > Here is a response I got by forwarding this to the pthreads maintainer:
> > > > > A return status of 0 from write is not interpreted as an End-Of-Tape.
> > > > > The threads library isn't smart enough to know that the file
> > > > > is a tape device and that a 0 status should break it out of the
> > > > > loop.  Thus, it continues writing.
> > > > >
> > > > > Use libkse :-)
> > > > >
> > > > > --
> > > > > Dan Eischen
> > >
> > > Nate: thanks for getting in touch with him.
> > >
> > > It is interesting to note that the code works OK on Linux and
> > > Solaris.  Why is FreeBSD different in this case?
> > 
> > I don't know.  Our pthreads implementation is purely userland so it's
> > likely that it is difficult to differentiate a non-blocking read from an
> > EOF.
> 
> Correct.

Can I ask a question?  When writing to a character/block special file
in non-blocking mode, are there any instances where 0 can be returned
from the write() other than when writing to a tape device?

The only way I can see to fix this in libc_r is to fstat() the
descriptor when the threads library initializes it (uthread_fd.c)
and save st_mode for that fd.  Then in write() check to see if
it is S_ISCHR() or S_ISBLK() and 0 was returned.  It could
break out of write() if that was the case and return 0 to
the caller.  But this doesn't work if you can get 0 back
from a write to other devices.

-- 
Dan Eischen