Mail Archives: djgpp-workers/2001/08/25/13:44:34
> > 3) This problem is masked on 2.03 due to call sequences which are different
> > (when using fstat, no one calls the get magic manually).
>
> ??? What do you mean by that? fstat _always_ tries to get the magic
> number if the handle refers to a file (not a character device).
If you call get_magic under 2.03 you can see the problem, but if you
call fstat() - which calls get_magic, you don't. So some sequence of
additional calls on the handle under 2.03 makes the problem go away.
More testing to find out why. What if we find some other interrupt
called before _get_magic on the same handle prevents the problem? That
would be a much better fix than slowing down each an every _read.
> > 4) This problem is masked on 2.04 if lfn=n due to call sequence differences
> > (when using fstat).
>
> And just to be sure we are talking about the same issue: by ``this
> problem'' do you mean the weird behvaior of read and lseek wrt file
> position? Or is there anything else?
The problem specifically is Andrew's original test problem using fstat()
on stdin and that causing subsequent calls to read to have missed the
first 2 characters in the file.
> > What I think, but must be confirmed:
> > 1) This problem is only seen on handle 0 when opened by NT, not Bash
>
> I think you saw similar problems on handle 1. The current hypothesis
> is that any handle opened by the NT shell will behave like that, which
> means handles 0-4 could potentially be affected.
I saw other problems on handle 1 - since reads failed completely on handle
1 there were not any missing data or offset problems. But getting the
current position did return bogus values on appended files. This could
eventually cause us to destroy all data in an appended handle by writing
to the start instead of appending.
> Sounds like a good plan to me. But if an extra seek solves the
> problem, why not try use it? We could make it part of this testing as
> well, to see whether it indeed solves the problems.
_read() is one of the most heavily used calls in the library. For all
DOS 5 systems we will be adding an extra interrupt to get true dos
version. For all NT systems we will be adding two new interrupts for
every read, the get dos version and a seek. And this may be for
a very specific problem that we don't even fix completely!
if we patch _read(), I would want a static variable for true_dos_version
set up, and to only do this for handle 0. If we are doing this, let's
also have get magic call _read instead so we don't have the patch multiple
places.
> > A similar problem is seen when redirecting from NUL for example - this is
> > shown as a regular file. We shouldn't be seeking on NUL, or reading
> > magic numbers, but we do today.
>
> We seek on NUL because we don't know it's a character device.
Exactly. I think we should fix the root problem of the strange redirected
handles instead of adding new interrupt calls to routines which will
slow everything down.
What about having _get_dev_info be smart about these?
- Raw text -