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

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, 5

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

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 as

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

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

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

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

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

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 qu

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

On Wed, Mar 17, 2004 at 11:50:48AM +, 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 w

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

[ 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

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

> -Original Message- > From: cygwin-owner On Behalf Of Jason Winter > Sent: 17 March 2004 02:22 > To: [EMAIL PROTECTED] > Subject: Re: read(): varblk tape records...(& Fix for : read()) [ Reader's Digest condensed version: ] > Considering that Cygwin is

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

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 you

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

On Wed, Mar 17, 2004 at 02:21:55AM +, 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 peo

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

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

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

On Tue, Mar 16, 2004 at 12:00:45PM +, Jason Winter wrote: >> > >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 rej

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

Hello responders, 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 experien

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

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 'f

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

Welcome to a night of cygwin mailing list misconceptions! On Tue, Mar 16, 2004 at 02:09:55AM +, 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

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

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] Igor --

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

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 pa

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 getti

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

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... Stran

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

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 protectio

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

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 on

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

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 progr

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

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

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

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 ()? ;-) Igor --

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

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? Bu

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

> 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

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

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 ve

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

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 record

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

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 havin

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

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

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

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 re

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

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:

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

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 ea

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

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

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

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 Linu

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

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 th

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

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.

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

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.

Re: read(): varblk tape records...

On Mar 1 13:32, Jason Winter wrote: > The NT API 'ReadFile' for reading variable block tape records indicates the > block length by returning only one full-block at a time (per read call) > which isn't being honored by CygWin's read() function. ??? > Can CygWin be changed to detect a *tape* re

read(): varblk tape records...

The NT API 'ReadFile' for reading variable block tape records indicates the block length by returning only one full-block at a time (per read call) which isn't being honored by CygWin's read() function. Can CygWin be changed to detect a *tape* read() call and not continue to fill the user-buffe