This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: read(): varblk tape records...(& Fix for : read())
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 15 Mar 2004 12:50:10 +0100
- Subject: Re: read(): varblk tape records...(& Fix for : read())
- References: <Sea2-F13cv46SQ4wpV40004e672@hotmail.com>
- Reply-to: cygwin at cygwin dot com
On Mar 15 01:02, Jason Winter wrote:
> 1/ Read buffer pointers are being reused by the write handler.
Shouldn't happen anymore.
> 2/ Possible drive-busy signal (in WinNT) leads to incomplete API result.
I don't quite understand this one. What means "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.
Are you talking about the values in mt_gstat? See below.
> 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.)
What cached flag?
> Some programs fail because they expect the BOT signal to disappear.
Cygwin programs?
> The close-filemark issue isn't really a problem, and the Win32 1101 error
It should be fixed. The close-filemark is written only if the very
last action was a write now. E. g. if you write and then seek, EOF
isn't written. This resembles more closely Linux driver behaviour.
> is being handled properly, I was just looking in the wrong file.
I was not sure how you meant it anyway.
If you have a look into the next snapshot, there's a bunch of changes
to the tape code. It's still not close to Linux since it's still
missing a few features which are a bit more compilicated to do as,
e.g., keeping track of the current fileno and file relative block as
well as setting GMT_EOF, GMT_BOT, GMT_EOT, GMT_SM and GMT_EOD correctly.
This requires a shared datastructure and critical section handling,
which isn't implemented yet.
I've also uploaded a new version of mt(1) which works better with
the new snapshot. It prints drive types and density codes (with
XP and 2K3) and it has two new commands `mkpart' and `setpart'.
Does anybody have a tape drive which has a Windows driver supporting
select partitions? I've implemented MTMKPART, which should behave
as the Linux driver and allows creating either one (count <= 0) or
two (count > 0) partitions, but that simple mechanism so far requires
the select partition ability (TAPE_DRIVE_SELECT). Unfortunately, the
Windows driver of my new tape drive seems a bit buggy or uncomplete.
The drive itself allows all three partitioning types (fixed, select,
initiator), but the driver is a bit dumb, apparently.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin@cygwin.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/