This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: read(): varblk tape records...(& Fix for : read())


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]