Mail Archives: cygwin/2004/03/05/05:20:34
On Mar 5 05:14, Jason Winter wrote:
> Hi Corinna,
>
> It turns out that your new fix (for read();) might (I'm not sure until the
> nightly builds are working again) prevent the bug from happening with
> var-blk records - but I think the 'bug' will still cause problems with
> fixed-block records and maybe other filetypes. The issue I'm having is:
> raw_read() is setting devbufstart & devbufend, and raw_write() checks
> devbufend for buffering (which isn't required with var-block records or
> properly written fixed-block records in any case.)
What means "properly"? It's not necessary with var-blocks, but it is
necessary with fixed blocks. If somebody writes 1200 bytes to a tape
set to 512 byte blocksize, raw_write writes 2 blocks (1024 bytes) to
the tape and buffers the remaining 176 bytes for the next write. How
should that work otherwise?
> My own feeling on this is, when reading tape-block data (fixed or variable
> blocks) and the blocks are not being buffered in calls (ie. my test-harness
> uses correctly sized buffers) then raw_read() shouldn't leave devbufstart
> or devbufend non-zero.
I don't quite understand what you mean. The first thing in raw_read()
is to call writebuf() which checks if devbuf is used as a write buffer
and if so, tries to write the data in the buffer onto the medium. This
also sets devbufstart and devbufend to zero. Am I missing something?
Unfortunately I can't run your testcase. My DDS tape drive seems to be
broken. It can read, but it behaves weird when trying to write :-(((
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -