Mail Archives: djgpp-workers/2001/08/22/12:14:19
> It looks like 4200 reports that it did move the file pointer, but the
> subsequent 3F00 still continues from the position before the lseek.
Yes, it appears NT has cached the location of the pointer (incorrectly)
and treats the a second call to set the absolute pointer position to
the same place as the previous call a no-operation. A get of the pointer
or a move to a different location fixes it.
> Right now, I'm more worried by lseek not working than by
> _is_executable. I think we need first to find a good general-purpose
> solution for lseek, so that we could be sure the file pointer moves to
> the right place. If that doesn't fix _is_executable, we can find some
> local trick later.
Agreed. So far in testing, doing a 4201 call with zero relative offset
(i.e. get position) seems to fix it. Probably putting this call in
_is_executable (and maybe lseek) would fix the problems. Or we make
the handle a pipe :-)
> Thanks, trying this with different shells might indeed shed some light
> on this problem.
This problem does not happen under bash on NT4.0. This indicates to me
even more the problem is only on NT opened handles.
I'll repeat that handles on NT can be real pipes also, and I don't
know how well seeking is supported on larger inputs. Pipes also have
the get_dev_info to be zero - so today we don't show a difference.
Also remember, that NT 4.0 and DJGPP have co-existed for 5 years, and
no one has reported this until now, so it's probably not a crisis to
fix it immediately. Using bash is a workaround.
- Raw text -