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/
