Date: Thu, 28 Aug 2003 13:48:54 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Nate Lawson <nate@root.org> Cc: Kern Sibbald <kern@sibbald.com> Subject: Re: (Fwd) Re: SCSI tape data loss Message-ID: <Pine.GSO.4.10.10308281338580.12975-100000@pcnet5.pcnet.com> In-Reply-To: <Pine.GSO.4.10.10308271433560.15517-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10308281338580.12975-100000>