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:[EMAIL PROTECTED] 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/
