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
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
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
[ 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
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
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
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
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...
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
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
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?
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
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
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
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
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-aupage=hotmail/es2
--
Unsubscribe info:
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
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
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
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
Hi Corinna,
(For continued reference:)
The Tape Block Length information is in MSDN, within the document Q161338
in the
knowledge base.
The CygWin read() function calls ReadFile() repeatedly while the programmers
read buffer-length parameter value #of bytes hasn't been read from the
handle.
21 matches
Mail list logo
