delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/03/15/06:50:44

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 15 Mar 2004 12:50:10 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: read(): varblk tape records...(& Fix for : read())
Message-ID: <20040315115010.GK25204@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <Sea2-F13cv46SQ4wpV40004e672 AT hotmail DOT com>
Mime-Version: 1.0
In-Reply-To: <Sea2-F13cv46SQ4wpV40004e672@hotmail.com>
User-Agent: Mutt/1.4.2i

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 AT cygwin DOT 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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019