From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10108251652.AA17486@clio.rice.edu> Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K) To: eliz AT is DOT elta DOT co DOT il Date: Sat, 25 Aug 2001 11:52:00 -0500 (CDT) Cc: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com In-Reply-To: <5567-Sat25Aug2001191247+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 25, 2001 07:12:48 PM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > 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?