(Fwd) Re: SCSI tape data loss
eischen at vigrid.com
Thu Aug 28 10:48:59 PDT 2003
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.
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.
More information about the freebsd-scsi