Mail Archives: djgpp-workers/2001/08/25/11:14:33
Guys, please just stop on this until futher testing.
From what I know:
1) This problem is not LFN specific.
2) This problem is not W2K specific (seen on NT 4.0)
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).
4) This problem is masked on 2.04 if lfn=n due to call sequence differences
(when using fstat).
What I think, but must be confirmed:
1) This problem is only seen on handle 0 when opened by NT, not Bash
2) We cannot distinguish handle 0 file NT-opened from real pipe 0 NT-opened
Tests I'd like to see first:
1) Does this happen on any handles opened with libc? If not then let's
narrow any tests in the future to handle 0,1,2,3,4 at worst.
2) Does this happen on any handle which _get_dev_info is not 0?
3) Does seek on pipes work? For example, prog1 | prog2 - lets say that
prog1 dumps 10 Megabytes down the pipe, can we reliably seek anyplace,
anytime in that 10Mb? I know that limited seeks *DO* work, for example
"dir | test" shows the magic as " V" and then is off by two chars. But
if I do the fix I can go back the two characters in the pipe. But how
far can I go? Should pipes really be marked executable?
4) Does rebuilt patch work on stdin() if built using a patched 2.03?
5) Does rebuilt patch work on stdin() if you force ISREG to be false?
Let's test and have a strategy first. I would rather just mark handle 0
with _get_dev_info as 0 as a character device so no one seeks on it
unless we can show seeks reliably work all the time, in all the situations.
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.
- Raw text -