Mail Archives: cygwin/2004/03/14/20:02:53
Hi Corinna,
>It's a bug in your my_read1 code.
Yes, I know... I fixed it (the protection-fault) the next day, but it
doesn't change the tapes behaviour.
Perhaps if I rewrite the outstanding issues another way, you might be
convinced to change the code even without a tape drive to test with...
Strange things in CygWin: (Tape-Fixed-Block.)
1/ Read buffer pointers are being reused by the write handler.
- This means writing buffer blocks might become 'staggered', by
'inserted' data from a previous read call. Rewind/Block-Seek
doesn't reset these pointers either - resulting in loss of
control over the tape device in some situations: Having seeked
a block, if a staggered write is incomplete, the next read will
fail due to a new block being written OVER the one just seeked
(since the read routine flushes any leftover write data first.)
2/ Possible drive-busy signal (in WinNT) leads to incomplete API result.
- This means getting drive stats while the drive is reading/writing
under NT may result in the CygWin wrapper returning the BOT signal
(Beginning Of Tape) even though it's currently writing that block.
And calling the NT API would return the new block number if CygWin
had used a cached flag instead (from when the drive wasn't busy.)
Some programs fail because they expect the BOT signal to disappear.
The close-filemark issue isn't really a problem, and the Win32 1101 error
is being handled properly, I was just looking in the wrong file.
Regards,
Jason.
_________________________________________________________________
Find love today with ninemsn personals. Click here:
http://ninemsn.match.com
--
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 -