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

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

[Jason Winter]

Hi Corinna,

The error for read() was 28, No space left on device, if that helps.
Jason.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to  
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2


--
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/

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

[Jason Winter]

Hi Corinna,

The error for read() was 28, No space left on device, if that helps.
Jason.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to  
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2


--
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/

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

[Corinna Vinschen]

On Mar  4 07:32, Jason Winter wrote:
> Hi Corinna,
> 
> The error for read() was 28, No space left on device, if that helps.

As I said, I need a testcase.  Please provide a brief source which
compiles OOTB and shows the problem.

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/

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

[Jason Winter]

>What is all this justifying yourself good for?

Isn't so.

>FWIW, I think I know better, too.  It takes a while but I do eventually
>get it.

I don't think so.

>That's 2 for 2.

Don't say it's so.
Jason.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to  
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2


--
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/

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

[Christopher Faylor]

On Thu, Mar 18, 2004 at 10:14:36AM +0100, Corinna Vinschen wrote:
>On Mar 18 08:40, Jason Winter wrote:
>>2 days before the question was asked, Corinna had already made the code
>>alteration that the question refered to.  Now who looks stupid.
>
>What is all this justifying yourself good for?  I asked you a question
>because I didn't understand what you were talking about (not for the
>first time, if you scan the thread in the ML archive).  The reply was
>that I should know better.  If I know better, I obviously don't have to
>pay attention to what you're telling.  Fine with me.

FWIW, I think I know better, too.  It takes a while but I do eventually
get it.

That's 2 for 2.

cgf

--
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/

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

[Jason Winter]

>>2 days before the question was asked, Corinna had already made the code
>>alteration that the question refered to.  Now who looks stupid.
>
>What is all this justifying yourself good for?  I asked you a question
>because I didn't understand what you were talking about (not for the
>first time, if you scan the thread in the ML archive).  The reply was
>that I should know better.  If I know better, I obviously don't have to
>pay attention to what you're telling.  Fine with me.

That answers that question.
(Just like I don't have to listen to you asking me: is the cygwin API 
failure in a Cygwin program?)

I'm sorry if you are offended by my "know better" coment.
Jason.

_________________________________________________________________
You could be a genius! Find out by taking the IQ Test 2003. $5.50 (incl 
GST).  Click here:  http://sites.ninemsn.com.au/minisite/testaustralia/


--
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/

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

[Corinna Vinschen]

On Mar 18 08:40, Jason Winter wrote:
> 2 days before the question was asked, Corinna had already made the code
> alteration that the question refered to.  Now who looks stupid.

What is all this justifying yourself good for?  I asked you a question
because I didn't understand what you were talking about (not for the
first time, if you scan the thread in the ML archive).  The reply was
that I should know better.  If I know better, I obviously don't have to
pay attention to what you're telling.  Fine with me.


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/

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

[Jason Winter]

>Perhaps I should have been clearer myself since I've been known to be
>*woefully* imprecise as well.  To attempt some additional clarity: On
>rereading your mail, I, a native English speaker, found myself
>scratching my head over what you were talking about.  So, I can
>understand Corinna's innocent question since, in my opinion, your intent
>was unclear.

2004-03-13  Corinna Vinschen  <corinna@vinschen.de>

	(class fhandler_dev_tape): Add TAPE_GET_DRIVE_PARAMETERS
	member `dp'.


2 days before the question was asked, Corinna had already made the code
alteration that the question refered to.  Now who looks stupid.

Regards,
Jason.

_________________________________________________________________
Personalise your phone with chart ringtones and polyphonics. Go to  
http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp


--
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/

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

[Christopher Faylor]

On Wed, Mar 17, 2004 at 11:50:48AM +0000, Jason Winter wrote:
>>Now it's me "of all people".
>
>No. It's you, Cygwin.  (A group of developers.)  Or *you* wouldn't be 
>replying to me as if you have some invested interest.

It's me, "Cygwin".  Ok.  At least you didn't call me Shirley.

>>The point was how little sense it makes to insult people by telling
>>them that they should know better.
>...
>>Obviously you were not explaining yourself very well and your
>>poor communication on this issue...
>
>That's your opinion, and at a minimum, is no less insulting.  (Thanks for 
>the lesson.)

Yes, it was certainly my opinion.  Make no mistake about that.  However,
it is also my opinion that it is not insulting to suggest that someone
was unclear on a specific issue.

Perhaps I should have been clearer myself since I've been known to be
*woefully* imprecise as well.  To attempt some additional clarity: On
rereading your mail, I, a native English speaker, found myself
scratching my head over what you were talking about.  So, I can
understand Corinna's innocent question since, in my opinion, your intent
was unclear.

Again, I did not say "you suck at communicating".  I said that you
weren't explaining yourself well on this issue.  However, you are again
not addressing the point, again, choosing to redirect it at me (i.e.,
"Cygwin").  The point?  Even if the rest of the cygwin populace found
your message crystal clear, IMO, the use of a hackle-raising observation
like "you should know better than to ask such a question" is not a
polite way to treat someone who volunteers their time to provide you
with a free service and is not conducive to future collaboration.  You
can take this observation or (most likely) leave it.

But, that's certainly it for me on this.  Thanks for your contributions
to this thread on tape handling, however.  I think it is obvious that
your willingness to work with Corinna prior to this point were to the
benefit of cygwin's tape handling code.  Although I'm sure that the
code worked fine for Corinna for her needs, she has taken some of her
time to make Cygwin more linux-like; which will undoubtedly benefit other
people in the future.
--
Christopher Faylor
Cygwin Project Leader
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/

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

[Jason Winter]

>[ That's about as much as you need to read to know how much the rest of the
>post is worth. ]

I'd agree, except for the first (original) post.  I'd send that again at 
least, even now.
Jason.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to  
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2


--
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/

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

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Jason Winter
> Sent: 17 March 2004 02:22
> To: cygwin@cygwin.com
> Subject: Re: read(): varblk tape records...(& Fix for : read())

[ Reader's Digest condensed version: ]

> Considering that Cygwin is a Linux wrapper for Windows,

[ That's about as much as you need to read to know how much the rest of the
post is worth. ]



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 


--
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/

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

[Jason Winter]

>Now it's me "of all people".

No. It's you, Cygwin.  (A group of developers.)  Or *you* wouldn't be 
replying to me as if you have some invested interest.

>The point was how little sense it makes to insult people by telling
>them that they should know better.
...
>Obviously you were not explaining yourself very well and your
>poor communication on this issue...

That's your opinion, and at a minimum, is no less insulting.  (Thanks for 
the lesson.)
Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here:  
http://ninemsn.seek.com.au?hotmail


--
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/

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

[Christopher Faylor]

On Wed, Mar 17, 2004 at 02:21:55AM +0000, Jason Winter wrote:
>>Fascinating.  You tell someone who is trying to help resolve your
>>problem that they should "know better" and then send "thanks and
>>regards".
>
>Considering that Cygwin is a Linux wrapper for Windows, I would
>expect you, of all people, to realise there are no true Cygwin
>programs 'out there' (esp. tape backup ones.)

Now it's me "of all people".

This is a typical usenet trick.  Fail to address the actual issue
and redirect the discussion.  We weren't talking about me.

The point was not what I knew or didn't know.  The point was how little
sense it makes to insult people by telling them that they should know
better.  Obviously you were not explaining yourself very well and your
poor communication on this issue compounded with the fact that Corinna
is not a native English speaker resulted in her asking for
clarification.

Instead of just providing the clarification you chose to editorialize
and potentially alienate.  It's certainly your perogative to do so but
I wouldn't imagine it to be an effective method for securing any future
cooperation even if your current issues with cygwin tape handling are
solved.
--
Christopher Faylor
Cygwin Project Leader
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/

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

[Jason Winter]

>Fascinating.  You tell someone who is trying to help resolve your
>problem that they should "know better" and then send "thanks and
>regards".

Considering that Cygwin is a Linux wrapper for Windows, I would
expect you, of all people, to realise there are no true Cygwin
programs 'out there' (esp. tape backup ones.)

But No.  I am helping to resolve *your* problems.  I've already stated
in previous emails that I don't use fixed-block tape access in
Cygwin, and frankly, I'm not likely to.

The main problem I was experiencing was fixed weeks ago now, and
these problems were just suggestions made from my reviewing the
Cygwin source code.  Let me know if you *don't* want 'em.

Regards,
Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here:  
http://ninemsn.seek.com.au?hotmail


--
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/

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

[Christopher Faylor]

On Tue, Mar 16, 2004 at 12:00:45PM +0000, Jason Winter wrote:
>><http://cygwin.com/ml/lists.html#rbl-sucks>
>
>Yep, there you go.

The unblocking information at that web page is also included in any
bounce message that you get if your email does not go through.

>>No.  The mailing list does not reject email that contains source code.
>
>That remark is relative to what's in the source code, and from my 
>experience - it does - and - that's using source code from cygwin itself.  
>No.  I don't want to argue the point.

If you don't want to argue the point then don't make the point.

Let me say it again -- no mailing list on sources.redhat.com rejects
source code.  There is a huge traffic in sending source code to mailing
lists at this site.  There is, however, a spam blocker in operation.  If
it rejects a message due to a false positive, it is trivially easy to
bypass that block.  That does not, of course, stop people from failing
to read the instructions on how to unblock themselves and/or being
mortally offended by the block.

>>>Some programs fail because they expect the BOT signal to disappear.
>>Cygwin programs?
>
>You should know better than to ask such a question! It would be more
>likey a Linux program (which it is - but converted to use fixed blocks,
>not variable blocks.)
>
>Thanks and regards,

Fascinating.  You tell someone who is trying to help resolve your
problem that they should "know better" and then send "thanks and
regards".
--
Christopher Faylor
Cygwin Project Leader
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/

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

[Jason Winter]

Hello responders,

><http://cygwin.com/ml/lists.html#rbl-sucks>
>	Igor

Yep, there you go.

>No.  The mailing list does not reject email that contains source code.
>--
>Christopher Faylor
>Cygwin Project Leader
>Red Hat, Inc.

That remark is relative to what's in the source code, and from my experience 
- it does - and - that's using source code from cygwin itself.  No.  I don't 
want to argue the point.

>Did you check the latest from CVS?
>Corinna

No, but looking now - you have cached the 'dp' variable (and hence the flag 
at issue) like I originally suggested.

>>Some programs fail because they expect the BOT signal to disappear.
>Cygwin programs?

You should know better than to ask such a question!  It would be more likey 
a Linux program (which it is - but converted to use fixed blocks, not 
variable blocks.)

Thanks and 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/

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

[Corinna Vinschen]

On Mar 16 02:09, Jason Winter wrote:
> Hi Corinna,
> 
> >Are you talking about the values in mt_gstat?  See below.
> 
> This mailing list rejects emails that contain source code (which isn't 
> 'attached' in a different file) so I can't easily show you what I mean:
> 
> Function 'tape_status' in 'fhandler_tape.cc' uses 'not' mt_blkno to see if 
> it's past the beg.of.tape, but it only updates that variable when function 
> 'tape_get_pos' is called.  It isn't called when 'FeaturesLow' doesn't have 
> the TAPE_DRIVE_GET_ABSOLUTE_BLK bit set, which happens when my tape drive 
> is busy and you request function 'GetTapeParameters'.  If you cache that 
> feature bit from when the drive wasn't busy, then you know you can call 
> 'tape_get_pos' even when the tape is busy and the feature can't be read 
> (dynamically, as it is now.)

Did you check the latest from CVS?

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/

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

[Christopher Faylor]

Welcome to a night of cygwin mailing list misconceptions!

On Tue, Mar 16, 2004 at 02:09:55AM +0000, Jason Winter wrote:
>>Are you talking about the values in mt_gstat?  See below.
>
>This mailing list rejects emails that contain source code (which isn't 
>'attached' in a different file) so I can't easily show you what I mean:

No.  The mailing list does not reject email that contains source code.
--
Christopher Faylor
Cygwin Project Leader
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/

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

[Igor Pechtchanski]

On Tue, 16 Mar 2004, Jason Winter wrote:

> [snip]
> This mailing list rejects emails that contain source code (which isn't
> 'attached' in a different file) so I can't easily show you what I mean:
> [snip]

<http://cygwin.com/ml/lists.html#rbl-sucks>
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

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

[Jason Winter]

Hi Corinna,

>Are you talking about the values in mt_gstat?  See below.

This mailing list rejects emails that contain source code (which isn't 
'attached' in a different file) so I can't easily show you what I mean:

Function 'tape_status' in 'fhandler_tape.cc' uses 'not' mt_blkno to see if 
it's past the beg.of.tape, but it only updates that variable when function 
'tape_get_pos' is called.  It isn't called when 'FeaturesLow' doesn't have 
the TAPE_DRIVE_GET_ABSOLUTE_BLK bit set, which happens when my tape drive is 
busy and you request function 'GetTapeParameters'.  If you cache that 
feature bit from when the drive wasn't busy, then you know you can call 
'tape_get_pos' even when the tape is busy and the feature can't be read 
(dynamically, as it is now.)

Regards,
Jason.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to  
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2


--
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/

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

[Corinna Vinschen]

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/

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

[Jason Winter]

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/

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

[Corinna Vinschen]

On Mar  6 08:20, Jason Winter wrote:
> Hi Corinna,
> 
> When you do get a working tape drive, here is an example of read making the 
> next write 'go bad'...
> 
> Fixed Blocks... which I don't use...  (Use a parameter on testtape.exe to 
> test both cases.)
> Jason.
> ps. Why did it get a protection-fault? maybe it's the cygwin1.dll snapshot, 
> but I only get it with *that* example where the API is failing.

It's a bug in your my_read1 code.

> void my_read1 (int fh) {
>    int rc;
>    int en;
>    char buf2 [1];
> 
>    printf ("read1...");
>    fflush (stdout);
>    memset (buf2, ' ', 10);
> 
>    errno = 0;
>    rc = read (fh, buf2, 1);
>    en = errno;
> 
>    printf (" rc=%d, errno=%d\n", rc, en);
>    buf2 [1] = 0;
     =============

>    printf ("%s\n", buf2);
>    disp_stat ();
>    common ();
> };

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/

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

[Jason Winter]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

Hi Corinna,

When you do get a working tape drive, here is an example of read making the 
next write 'go bad'...

Fixed Blocks... which I don't use...  (Use a parameter on testtape.exe to 
test both cases.)
Jason.
ps. Why did it get a protection-fault? maybe it's the cygwin1.dll snapshot, 
but I only get it with *that* example where the API is failing.

_________________________________________________________________
What's your house worth? Click here to find out:  
http://www.ninemsn.realestate.com.au

[-- Attachment #2: FBWERR.TXT --]
[-- Type: text/plain, Size: 1692 bytes --]

run1: fixed-block, with 'proper' reads of block-length
c:\testtape

Opening Tape Handle
stblk.mt_blkno=0
ST0: Status: 41030000 BOT ON-LINE
Setting length 512 records. rc=0
ST0: Status: 41030000 BOT ON-LINE
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
write... rc=512, errno=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
backspace... rc=0
ST0: Status: 41030000 BOT ON-LINE
stblk.mt_blkno=0
read... rc=512, errno=0
AC23456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
write... rc=512, errno=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
backspace... rc=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
read... rc=512, errno=0
BD23456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
Closing Tape Handle

run2: with first-read only reading 1 character:
c:\testtape read1

Opening Tape Handle
stblk.mt_blkno=0
ST0: Status: 41030000 BOT ON-LINE
Setting length 512 records. rc=0
ST0: Status: 41030000 BOT ON-LINE
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
write... rc=512, errno=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
backspace... rc=0
ST0: Status: 41030000 BOT ON-LINE
stblk.mt_blkno=0
read1... rc=1, errno=0
A
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
write... rc=512, errno=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
backspace... rc=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
read... rc=-1, errno=28

ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
Closing Tape Handle
      9 [main] testtape 102 handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
   6056 [main] testtape 102 open_stackdumpfile: Dumping stack trace to 
testtape.exe.stackdump



[-- Attachment #3: testtape.c --]
[-- Type: text/plain, Size: 3691 bytes --]

//#include <io.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/mtio.h>

int fh;
struct mtget stblk;
struct mtop  opblk;

#define BLKLEN 512
#define RBLKLEN 512
//#define RBLKLEN 65535 // var blks only

char buf [BLKLEN] = "0123456789";

void disp_stat () {
    int  stat;
    char buf [256];

    ioctl (fh, MTIOCGET, (char*)&stblk);
    stat = stblk.mt_gstat;

    /* Display tape status */
    sprintf (buf, "Status: %8.8X", stat);
    if (GMT_EOF(stat)) strcat (buf, " EOF");
    if (GMT_BOT(stat)) strcat (buf, " BOT");
    if (GMT_EOT(stat)) strcat (buf, " EOT");
    if (GMT_SM(stat)) strcat (buf, " SET-MARK");
    if (GMT_EOD(stat)) strcat (buf, " EOD");
    if (GMT_WR_PROT(stat)) strcat (buf, " WR-PROT");
    if (GMT_ONLINE(stat)) strcat (buf, " ON-LINE");
    if (GMT_D_6250(stat)) strcat (buf, " 6250");
    if (GMT_D_1600(stat)) strcat (buf, " 1600");
    if (GMT_D_800(stat)) strcat (buf, " 800");
    if (GMT_DR_OPEN(stat)) strcat (buf, " NO-TAPE");

    printf ("ST0: %s\n", buf);
};

void common () {
    printf ("stblk.mt_blkno=%d\n", stblk.mt_blkno);
};

void set_blk (int len) {
    int rc;

    if (len)
        printf ("Setting length %d records.", len);
    else
        printf ("Setting variable records.");
    fflush (stdout);

    opblk.mt_op = MTSETBLK;
    opblk.mt_count = len;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);

    printf (" rc=%d\n", rc);
};

void my_read (int fh) {
    int rc;
    int en;
    char buf2 [RBLKLEN];

    printf ("read...");
    fflush (stdout);
    memset (buf2, ' ', 10);

    errno = 0;
    rc = read (fh, buf2, RBLKLEN);
    en = errno;

    printf (" rc=%d, errno=%d\n", rc, en);
    buf2 [10] = 0;
    printf ("%s\n", buf2);
    disp_stat ();
    common ();
};

void my_read1 (int fh) {
    int rc;
    int en;
    char buf2 [1];

    printf ("read1...");
    fflush (stdout);
    memset (buf2, ' ', 10);

    errno = 0;
    rc = read (fh, buf2, 1);
    en = errno;

    printf (" rc=%d, errno=%d\n", rc, en);
    buf2 [1] = 0;
    printf ("%s\n", buf2);
    disp_stat ();
    common ();
};

void my_write (int fh) {
    int rc;
    int en;

    printf ("write...");
    fflush (stdout);

    errno = 0;
    rc = write (fh, buf, BLKLEN);
    en = errno;

    printf (" rc=%d, errno=%d\n", rc, en);
    disp_stat ();
    common ();
};

void my_bksp (int fh) {
    int rc;

    printf ("backspace...");
    fflush (stdout);
    opblk.mt_op = MTBSR;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
    printf (" rc=%d\n", rc);
    disp_stat ();
    common ();
};

void my_rew (int fh) {
    int rc;

    printf ("rewind...");
    fflush (stdout);
    opblk.mt_op = MTREW;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
    printf (" rc=%d\n", rc);
    disp_stat ();
};

int main (int argc) {
    int rc;

    printf ("Opening Tape Handle\n");

    fh = open ("/dev/st0", O_RDWR);
    if (fh >= 0) {

        rc = ioctl (fh, MTIOCGET, (char*)&stblk);
        if (rc < 0) {
            printf ("Failed to IOCTL the Tape\n");
        } else {
            common ();
        };

        disp_stat ();
        set_blk (BLKLEN);
        disp_stat ();
        my_rew (fh);

        buf [0] = 'A';
        buf [1] = 'C';
        my_write (fh);
        my_bksp (fh);

        if (argc == 1)
            my_read (fh);
        else
            my_read1 (fh); // special 1 char read

        buf [0] = 'B';
        buf [1] = 'D';
        my_write (fh);
        my_bksp (fh);
        my_read (fh);
        my_rew (fh);

        printf ("Closing Tape Handle\n");
        close (fh);

    } else {

        printf ("Failed to Open Tape\n");
    };

    return (0);
};



[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

--
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/

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

[Jason Winter]

Hi Corinna,

>This will stop me working on the tape handling in Cygwin until I got a
>new tape from somewhere :-(

Well, I'll stick to variable-block tapes then - I've tested the first 
march-snapshot cygwin1.dll and it's working for me.  (Although, I think only 
because the cygwin API *and* the program which processes tapes checks 
tape_status more often than is required - which is preventing the problem 
where updating the current block number indicator gets skipped because my 
drive is busy...  Is this a normal thing?)

I hope you get a working tape unit soon.
Jason.
ps. Yes, Bill - not Igor.  Sorry.

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to  
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2


--
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/

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

[Corinna Vinschen]

On Mar  5 14:27, Jason Winter wrote:
> Hi Corinna,
> 
> >Unfortunately I can't run your testcase.  My DDS tape drive seems to be
> >broken.  It can read, but it behaves weird when trying to write :-(((
> 
> Doesn't it worry you, that we both have write problems?

My DDS drive can't write even with native tools anymore.  I'm getting
CRC errors when trying to write more than one block, rewind after
write or when trying to erase the tape.  It's very annoying since the
drive seems to seek the tape randomly for a good minute before the CRC
error is reported.  Cleaning the drive or trying various, also fresh
tapes didn't help either. 

This will stop me working on the tape handling in Cygwin until I got a
new tape from somewhere :-(


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/

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

[Igor Pechtchanski]

On Fri, 5 Mar 2004, Jason Winter wrote:

> [snip]
> ps. Igor, I thought my DAT drive was broken for weeks, until I used the NT
> API directly...

Huh?  Did I miss a message from an Igor in this thread?  Or do you mean
Bill (<http://cygwin.com/ml/cygwin/2004-03/msg00288.html>)? ;-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

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

[Jason Winter]

Hi Corinna,

>I don't quite understand what you mean.  The first thing in raw_read()
>is to call writebuf() which checks if devbuf is used as a write buffer
>and if so, tries to write the data in the buffer onto the medium.  This
>also sets devbufstart and devbufend to zero.  Am I missing something?

But what about calling read() first, then write().

So, read() sets the writing flag off, and flushes any data that needs it,
then uses devbufstart etc. and leaves it in a non-zero state.

Now write() gets called.  writing flag is no: so devbufend is assigned to
devbufstart (which is non-zero) and devbufstart is reset to 0.

Now, write() starts to process buffers!  But these buffers are not write
buffers!  They are leftover read buffers (and as I wrote before, doesn't
effect val-blk-writes due to other code-paths.)

Or, am I missing something?
Jason.
ps. Igor, I thought my DAT drive was broken for weeks, until I used the NT 
API directly...

_________________________________________________________________
Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to  
http://join.msn.com/?pgmarket=en-au&page=hotmail/es2


--
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/

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

[Hughes, Bill]

> Sent: 05 March 2004 10:20 From: Corinna Vinschen 
..snip..
> Unfortunately I can't run your testcase.  My DDS tape drive 
> seems to be
> broken.  It can read, but it behaves weird when trying to write :-(((

Unfortunately that seems perfectly normally for DDS drives.
We even have a DDS3 that can now only read DDS1+2.
Where one friend works they even started buying them in pairs to have spare
when the first one breaks.
You might try disassembly and vacuuming if you're so inclined, sometimes
works, but not often :-(

Bill
--

--
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/

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

[Jason Winter]

Hi Corinna,

>Unfortunately I can't run your testcase.  My DDS tape drive seems to be
>broken.  It can read, but it behaves weird when trying to write :-(((

Doesn't it worry you, that we both have write problems?  When I stick to 
reading, everything works just fine also.  Do you want my Native NT version 
- it works perfectly?

Here are some other things I've noticed:

1/ close() writes a file-mark in some cases... Don't, I can do this myself, 
thank's anyway!

2/ read() should check for Win32 error 1101 - filemark and return 0 bytes, 
no error.

3/ tape_status dynamically checks 'tape_drive_get_absolute_blk', before 
calling
   tape_get_pos () : but my tape drive says '0' when it's busy, preventing 
the current
   block from being updated *sometimes*.  Force-reading it works just fine, 
if you want to
   cache the flag somewhere when the device is opened?

4/ sending a tape-rewind command doesn't reset any internal flags, does it 
need to?

Jason.

_________________________________________________________________
Protect your inbox from harmful viruses with new ninemsn Premium. Go to   
http://ninemsn.com.au/premium/landing.asp?banner=emailtag&referrer=hotmail


--
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/

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

[Corinna Vinschen]

On Mar  5 05:14, Jason Winter wrote:
> Hi Corinna,
> 
> It turns out that your new fix (for read();) might (I'm not sure until the 
> nightly builds are working again) prevent the bug from happening with 
> var-blk records - but I think the 'bug' will still cause problems with 
> fixed-block records and maybe other filetypes.  The issue I'm having is: 
> raw_read() is setting devbufstart & devbufend, and raw_write() checks 
> devbufend for buffering (which isn't required with var-block records or 
> properly written fixed-block records in any case.)

What means "properly"?  It's not necessary with var-blocks, but it is
necessary with fixed blocks.  If somebody writes 1200 bytes to a tape
set to 512 byte blocksize, raw_write writes 2 blocks (1024 bytes) to
the tape and buffers the remaining 176 bytes for the next write.  How
should that work otherwise?

> My own feeling on this is, when reading tape-block data (fixed or variable 
> blocks) and the blocks are not being buffered in calls (ie. my test-harness 
> uses correctly sized buffers) then raw_read() shouldn't leave devbufstart 
> or devbufend non-zero.

I don't quite understand what you mean.  The first thing in raw_read()
is to call writebuf() which checks if devbuf is used as a write buffer
and if so, tries to write the data in the buffer onto the medium.  This
also sets devbufstart and devbufend to zero.  Am I missing something?

Unfortunately I can't run your testcase.  My DDS tape drive seems to be
broken.  It can read, but it behaves weird when trying to write :-(((


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/

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

[Jason Winter]

Hi Corinna,

It turns out that your new fix (for read();) might (I'm not sure until the 
nightly builds are working again) prevent the bug from happening with 
var-blk records - but I think the 'bug' will still cause problems with 
fixed-block records and maybe other filetypes.  The issue I'm having is: 
raw_read() is setting devbufstart & devbufend, and raw_write() checks 
devbufend for buffering (which isn't required with var-block records or 
properly written fixed-block records in any case.)

My own feeling on this is, when reading tape-block data (fixed or variable 
blocks) and the blocks are not being buffered in calls (ie. my test-harness 
uses correctly sized buffers) then raw_read() shouldn't leave devbufstart or 
devbufend non-zero.

Hope this helps more,
Jason.

_________________________________________________________________
Personalise your phone with chart ringtones and polyphonics. Go to  
http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp


--
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/

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

[Jason Winter]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

Hi Corinna,

As requested, the program which produces the run1/run2 output.

I also have a Native-NT version of the same program (which works 
as-expected, if you would like to see it too let me know.)

Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au?hotmail

[-- Attachment #2: testtape.c --]
[-- Type: text/plain, Size: 3166 bytes --]

//#include <io.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/mtio.h>

int fh;
struct mtget stblk;
struct mtop  opblk;

#define BLKLEN 512

char buf [BLKLEN] = "0123456789";

void disp_stat () {
    int  stat;
    char buf [256];

    ioctl (fh, MTIOCGET, (char*)&stblk);
    stat = stblk.mt_gstat;

    /* Display tape status */
    sprintf (buf, "Status: %8.8X", stat);
    if (GMT_EOF(stat)) strcat (buf, " EOF");
    if (GMT_BOT(stat)) strcat (buf, " BOT");
    if (GMT_EOT(stat)) strcat (buf, " EOT");
    if (GMT_SM(stat)) strcat (buf, " SET-MARK");
    if (GMT_EOD(stat)) strcat (buf, " EOD");
    if (GMT_WR_PROT(stat)) strcat (buf, " WR-PROT");
    if (GMT_ONLINE(stat)) strcat (buf, " ON-LINE");
    if (GMT_D_6250(stat)) strcat (buf, " 6250");
    if (GMT_D_1600(stat)) strcat (buf, " 1600");
    if (GMT_D_800(stat)) strcat (buf, " 800");
    if (GMT_DR_OPEN(stat)) strcat (buf, " NO-TAPE");

    printf ("ST0: %s\n", buf);
};

void common () {
    printf ("stblk.mt_blkno=%d\n", stblk.mt_blkno);
};

void set_blk (int len) {
    int rc;

    if (len)
        printf ("Setting length %d records.", len);
    else
        printf ("Setting variable records.");
    fflush (stdout);

    opblk.mt_op = MTSETBLK;
    opblk.mt_count = len;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);

    printf (" rc=%d\n", rc);
};

void my_read (int fh) {
    int rc;
    char buf2 [65535];

    printf ("read...");
    fflush (stdout);
    memset (buf2, ' ', 10);
    rc = read (fh, buf2, 65535);
    printf (" rc=%d\n", rc);
    buf2 [10] = 0;
    printf ("%s\n", buf2);
    disp_stat ();
    common ();
};

void my_write (int fh) {
    int rc;

    printf ("write...");
    fflush (stdout);
    rc = write (fh, buf, BLKLEN);
    printf (" rc=%d\n", rc);
    disp_stat ();
    common ();
};

void my_bksp (int fh) {
    int rc;

    printf ("backspace...");
    fflush (stdout);
    opblk.mt_op = MTBSR;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
    printf (" rc=%d\n", rc);
    disp_stat ();
    common ();
};

void my_rew (int fh) {
    int rc;

    printf ("rewind...");
    fflush (stdout);
    opblk.mt_op = MTREW;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
    printf (" rc=%d\n", rc);
    disp_stat ();
};

int main (int argc) {
    int rc;

    printf ("Opening Tape Handle\n");

    fh = open ("/dev/st0", O_RDWR);
    if (fh >= 0) {

        rc = ioctl (fh, MTIOCGET, (char*)&stblk);
        if (rc < 0) {
            printf ("Failed to IOCTL the Tape\n");
        } else {
            common ();
        };

        disp_stat ();
        set_blk (0);

        disp_stat ();
        my_rew (fh);

        buf [0] = 'A';
        my_write (fh);
        my_bksp (fh);
        my_read (fh);

        if (argc != 1) { // Use any parameter to test this case.

            set_blk (0);
            disp_stat ();
        };

        buf [0] = 'B';
        my_write (fh);
        my_bksp (fh);
        my_read (fh);
        my_rew (fh);

        printf ("Closing Tape Handle\n");
        close (fh);

    } else {

        printf ("Failed to Open Tape\n");
    };

    return (0);
};



[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

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

[Jason Winter]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

Hi Corinna,

As requested, the program which produces the run1/run2 output.

I also have a Native-NT version of the same program (which works 
as-expected, if you would like to see it too let me know.)

Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au?hotmail

[-- Attachment #2: testtape.c --]
[-- Type: text/plain, Size: 3166 bytes --]

//#include <io.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/mtio.h>

int fh;
struct mtget stblk;
struct mtop  opblk;

#define BLKLEN 512

char buf [BLKLEN] = "0123456789";

void disp_stat () {
    int  stat;
    char buf [256];

    ioctl (fh, MTIOCGET, (char*)&stblk);
    stat = stblk.mt_gstat;

    /* Display tape status */
    sprintf (buf, "Status: %8.8X", stat);
    if (GMT_EOF(stat)) strcat (buf, " EOF");
    if (GMT_BOT(stat)) strcat (buf, " BOT");
    if (GMT_EOT(stat)) strcat (buf, " EOT");
    if (GMT_SM(stat)) strcat (buf, " SET-MARK");
    if (GMT_EOD(stat)) strcat (buf, " EOD");
    if (GMT_WR_PROT(stat)) strcat (buf, " WR-PROT");
    if (GMT_ONLINE(stat)) strcat (buf, " ON-LINE");
    if (GMT_D_6250(stat)) strcat (buf, " 6250");
    if (GMT_D_1600(stat)) strcat (buf, " 1600");
    if (GMT_D_800(stat)) strcat (buf, " 800");
    if (GMT_DR_OPEN(stat)) strcat (buf, " NO-TAPE");

    printf ("ST0: %s\n", buf);
};

void common () {
    printf ("stblk.mt_blkno=%d\n", stblk.mt_blkno);
};

void set_blk (int len) {
    int rc;

    if (len)
        printf ("Setting length %d records.", len);
    else
        printf ("Setting variable records.");
    fflush (stdout);

    opblk.mt_op = MTSETBLK;
    opblk.mt_count = len;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);

    printf (" rc=%d\n", rc);
};

void my_read (int fh) {
    int rc;
    char buf2 [65535];

    printf ("read...");
    fflush (stdout);
    memset (buf2, ' ', 10);
    rc = read (fh, buf2, 65535);
    printf (" rc=%d\n", rc);
    buf2 [10] = 0;
    printf ("%s\n", buf2);
    disp_stat ();
    common ();
};

void my_write (int fh) {
    int rc;

    printf ("write...");
    fflush (stdout);
    rc = write (fh, buf, BLKLEN);
    printf (" rc=%d\n", rc);
    disp_stat ();
    common ();
};

void my_bksp (int fh) {
    int rc;

    printf ("backspace...");
    fflush (stdout);
    opblk.mt_op = MTBSR;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
    printf (" rc=%d\n", rc);
    disp_stat ();
    common ();
};

void my_rew (int fh) {
    int rc;

    printf ("rewind...");
    fflush (stdout);
    opblk.mt_op = MTREW;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
    printf (" rc=%d\n", rc);
    disp_stat ();
};

int main (int argc) {
    int rc;

    printf ("Opening Tape Handle\n");

    fh = open ("/dev/st0", O_RDWR);
    if (fh >= 0) {

        rc = ioctl (fh, MTIOCGET, (char*)&stblk);
        if (rc < 0) {
            printf ("Failed to IOCTL the Tape\n");
        } else {
            common ();
        };

        disp_stat ();
        set_blk (0);

        disp_stat ();
        my_rew (fh);

        buf [0] = 'A';
        my_write (fh);
        my_bksp (fh);
        my_read (fh);

        if (argc != 1) { // Use any parameter to test this case.

            set_blk (0);
            disp_stat ();
        };

        buf [0] = 'B';
        my_write (fh);
        my_bksp (fh);
        my_read (fh);
        my_rew (fh);

        printf ("Closing Tape Handle\n");
        close (fh);

    } else {

        printf ("Failed to Open Tape\n");
    };

    return (0);
};



[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

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

[Jason Winter]

Hi Corinna,

>>If read() turns out to need a change, could you also check why I need to 
>>set varblk mode before each write to remind the API what's going on - from 
>>what I remember a second write returns an error unless I reset varblk mode 
>>each time.  (I call a routine to set it [was:'to'] before each read and 
>>write, just to be sure... but would like to know that all the extra code 
>>can be removed at some time later.)
>
>Please provide a brief test case to reproduce that problem.  I don't see
>that happening.

The "end-problem" is read() failing with -1 when it should have a tape block 
ready to read, and if setblk is used for each write - it does find the 
correct block.

Each run uses a 512 byte buffed with 0123456789...
Each write replaces the leading 0 with A, B etc.
Used SCSI TAPE commands: BackSpace, Rewind, SetBlock
--------------------------------------------------
    opblk.mt_op = MTBSR;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
--------------------------------------------------
    opblk.mt_op = MTREW;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
--------------------------------------------------
    opblk.mt_op = MTSETBLK;
    opblk.mt_count = len; // (len=0)
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
--------------------------------------------------

Run1: With *2* set-var-blk statements...

Opening Tape Handle
stblk.mt_blkno=0
ST0: Status: 41030000 BOT ON-LINE
Setting variable records. rc=0
ST0: Status: 41030000 BOT ON-LINE
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
backspace... rc=0
ST0: Status: 41030000 BOT ON-LINE
stblk.mt_blkno=0
read... rc=512
A123456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
Setting variable records. rc=0
ST0: Status: 01030000 ON-LINE
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
backspace... rc=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
read... rc=512
B123456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
Closing Tape Handle

==========================================

Run2: With *only 1* set-var-blk statement...

Opening Tape Handle
stblk.mt_blkno=0
ST0: Status: 41030000 BOT ON-LINE
Setting variable records. rc=0
ST0: Status: 41030000 BOT ON-LINE
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
backspace... rc=0
ST0: Status: 41030000 BOT ON-LINE
stblk.mt_blkno=0
read... rc=512
A123456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
backspace... rc=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
read... rc=-1

ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
Closing Tape Handle

In run2, the second read consistently fails (with no known ERRNO set.)

Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au?hotmail


--
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/

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

[Jason Winter]

Hi Corinna,

>>If read() turns out to need a change, could you also check why I need to 
>>set varblk mode before each write to remind the API what's going on - from 
>>what I remember a second write returns an error unless I reset varblk mode 
>>each time.  (I call a routine to set it [was:'to'] before each read and 
>>write, just to be sure... but would like to know that all the extra code 
>>can be removed at some time later.)
>
>Please provide a brief test case to reproduce that problem.  I don't see
>that happening.

The "end-problem" is read() failing with -1 when it should have a tape block 
ready to read, and if setblk is used for each write - it does find the 
correct block.

Each run uses a 512 byte buffed with 0123456789...
Each write replaces the leading 0 with A, B etc.
Used SCSI TAPE commands: BackSpace, Rewind, SetBlock
--------------------------------------------------
    opblk.mt_op = MTBSR;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
--------------------------------------------------
    opblk.mt_op = MTREW;
    opblk.mt_count = 1;
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
--------------------------------------------------
    opblk.mt_op = MTSETBLK;
    opblk.mt_count = len; // (len=0)
    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);
--------------------------------------------------

Run1: With *2* set-var-blk statements...

Opening Tape Handle
stblk.mt_blkno=0
ST0: Status: 41030000 BOT ON-LINE
Setting variable records. rc=0
ST0: Status: 41030000 BOT ON-LINE
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
backspace... rc=0
ST0: Status: 41030000 BOT ON-LINE
stblk.mt_blkno=0
read... rc=512
A123456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
Setting variable records. rc=0
ST0: Status: 01030000 ON-LINE
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
backspace... rc=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
read... rc=512
B123456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
Closing Tape Handle

==========================================

Run2: With *only 1* set-var-blk statement...

Opening Tape Handle
stblk.mt_blkno=0
ST0: Status: 41030000 BOT ON-LINE
Setting variable records. rc=0
ST0: Status: 41030000 BOT ON-LINE
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
backspace... rc=0
ST0: Status: 41030000 BOT ON-LINE
stblk.mt_blkno=0
read... rc=512
A123456789
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
write... rc=512
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
backspace... rc=0
ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=1
read... rc=-1

ST0: Status: 01030000 ON-LINE
stblk.mt_blkno=2
rewind... rc=0
ST0: Status: 41030000 BOT ON-LINE
Closing Tape Handle

In run2, the second read consistently fails (with no known ERRNO set.)

Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au?hotmail


--
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/

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

[Jason Winter]

Hi Corinna,

>>If read() turns out to need a change, could you also check why I need to 
>>set varblk mode before each write to remind the API what's going on - from 
>>what I remember a second write returns an error unless I reset varblk mode 
>>each time.  (I call a routine to set to before each read and write, just 
>>to be sure... but would like to know that all the extra code can be 
>>removed at some time later.)
>
>Please provide a brief test case to reproduce that problem.  I don't see
>that happening.
>
>Corinna

I'm not sure I can, you see: in fixing read, my original failed execution 
now works.  It was a write, backspace, read, write - where the second write 
fails.  Is it possible that calling:

    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);

simply resets the error (generated by the old read() routine) and that's why 
I thought it needed it?

Thanks for fixing the main issue, your support is very good and welcome!
Jason.

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp


--
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/

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

[Jason Winter]

Hi Corinna,

>>If read() turns out to need a change, could you also check why I need to 
>>set varblk mode before each write to remind the API what's going on - from 
>>what I remember a second write returns an error unless I reset varblk mode 
>>each time.  (I call a routine to set to before each read and write, just 
>>to be sure... but would like to know that all the extra code can be 
>>removed at some time later.)
>
>Please provide a brief test case to reproduce that problem.  I don't see
>that happening.
>
>Corinna

I'm not sure I can, you see: in fixing read, my original failed execution 
now works.  It was a write, backspace, read, write - where the second write 
fails.  Is it possible that calling:

    rc = ioctl (fh, MTIOCTOP, (char*)&opblk);

simply resets the error (generated by the old read() routine) and that's why 
I thought it needed it?

Thanks for fixing the main issue, your support is very good and welcome!
Jason.

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp


--
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/

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

[Corinna Vinschen]

On Mar  2 12:03, Jason Winter wrote:
> If you could look into that it would be great.  I know there's a few 
> 'Hercules mainframe' emulator users who would like to get their tape drives 
> working, and I think this will fix it.

I've checked in a fix.  Variable block reads should behave as on Linux
now, reading only one block and returning its size.  If the user supplied
buffer is too small for the block, the block is read but read() returns
ENOMEM.

> You are right, I've not looked at the Cygwin source code...  Only traced my 
> own programs to fix the difference I've discovered in the APIs.  Could I 
> ask why you need to allocate a buffer and then copy it to the buffer I 
> supply?  Wouldn't it be easier to calculate a new address when calling 
> ReadFile and do without the extra memcpy?  Just thinking of speed, needless 
> mem-copies and needless buffers.

Think a bit about the situation in general.  Especially in cases where
the user supplied buffer is smaller than the block size.  Due to the
above change, the variable block size reading doesn't need the internal
buffer anymore but the static buffer size reads still need it.

> If read() turns out to need a change, could you also check why I need to 
> set varblk mode before each write to remind the API what's going on - from 
> what I remember a second write returns an error unless I reset varblk mode 
> each time.  (I call a routine to set to before each read and write, just to 
> be sure... but would like to know that all the extra code can be removed at 
> some time later.)

Please provide a brief test case to reproduce that problem.  I don't see
that happening.

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/

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

[Jason Winter]

Hi Corinna,

If you could look into that it would be great.  I know there's a few 
'Hercules mainframe' emulator users who would like to get their tape drives 
working, and I think this will fix it.

You are right, I've not looked at the Cygwin source code...  Only traced my 
own programs to fix the difference I've discovered in the APIs.  Could I ask 
why you need to allocate a buffer and then copy it to the buffer I supply?  
Wouldn't it be easier to calculate a new address when calling ReadFile and 
do without the extra memcpy?  Just thinking of speed, needless mem-copies 
and needless buffers.

If read() turns out to need a change, could you also check why I need to set 
varblk mode before each write to remind the API what's going on - from what 
I remember a second write returns an error unless I reset varblk mode each 
time.  (I call a routine to set to before each read and write, just to be 
sure... but would like to know that all the extra code can be removed at 
some time later.)

Thanks,
Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au/


--
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/

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

[Jason Winter]

Hi Corinna,

If you could look into that it would be great.  I know there's a few 
'Hercules mainframe' emulator users who would like to get their tape drives 
working, and I think this will fix it.

You are right, I've not looked at the Cygwin source code...  Only traced my 
own programs to fix the difference I've discovered in the APIs.  Could I ask 
why you need to allocate a buffer and then copy it to the buffer I supply?  
Wouldn't it be easier to calculate a new address when calling ReadFile and 
do without the extra memcpy?  Just thinking of speed, needless mem-copies 
and needless buffers.

If read() turns out to need a change, could you also check why I need to set 
varblk mode before each write to remind the API what's going on - from what 
I remember a second write returns an error unless I reset varblk mode each 
time.  (I call a routine to set to before each read and write, just to be 
sure... but would like to know that all the extra code can be removed at 
some time later.)

Thanks,
Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au/


--
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/

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

[Corinna Vinschen]

On Mar  2 10:51, Jason Winter wrote:
> Hi Corinna,
> 
> Rereading the MSDN: Q161338 document I refered to before, Cygwin will need 
> to use a minimum 128KB buffer when 'reading' data from tapes - the NT 
> specification doesn't allow access to the 'last bytes' in a variable-block 
> any other way.  128KB allows for any SCSI device under windows.

If you have a look into the source code, you'll see that Cygwin in variable
block size case creates a buffer of the maximum block size allowed by the
tape drive (or driver), returned by GetTapeParameters().

I've not investigated so far if read behaves correctly or not, but now
I understand what you're up to.  I'll look into it.

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/

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

[Jason Winter]

Hi Corinna,

Rereading the MSDN: Q161338 document I refered to before, Cygwin will need 
to use a minimum 128KB buffer when 'reading' data from tapes - the NT 
specification doesn't allow access to the 'last bytes' in a variable-block 
any other way.  128KB allows for any SCSI device under windows.

(I noticed there was a memcpy for each ReadFile call - so I assume CygWin 
uses its own internal buffers, which may or maynot be large enough for tape 
support.)
Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au/


--
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/

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

[Jason Winter]

Hi Corinna,

Rereading the MSDN: Q161338 document I refered to before, Cygwin will need 
to use a minimum 128KB buffer when 'reading' data from tapes - the NT 
specification doesn't allow access to the 'last bytes' in a variable-block 
any other way.  128KB allows for any SCSI device under windows.

(I noticed there was a memcpy for each ReadFile call - so I assume CygWin 
uses its own internal buffers, which may or maynot be large enough for tape 
support.)
Jason.

_________________________________________________________________
SEEK: Now with over 50,000 dream jobs! Click here  
http://ninemsn.seek.com.au/


--
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/