Date: Sun, 26 Aug 2001 16:25:46 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K) In-Reply-To: <10108260745.AA16764@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Sun, 26 Aug 2001, Charles Sandmann wrote: > If the amount of data is small, it stays completely in memory. If the > amount of data becomes large, it creates a file in the %TEMP% directory > to buffer the data. Actually, it's possible that it always goes to the temporary file, but due to disk caching, if the file is small, it gets consumed before the cache is flushed. Assuming that the OS allows one application to read a file while another writes to its end (I already know that NT supports that, since "tail -f" works as expected on NT), you can have a credible pipe simulation with a disk file. > So, my dir \ /s on my disk takes over 4Mb. I > piped that to a djgpp app which would read, seek, read, seek, etc. > Eventually I could read/seek anywhere in the pipe - by that time it > buffered the entire thing to disk. The fact that the pipe is seekable is actually an evidence that it's disk based. The strange behavior wrt seeking is probably due to the jugglying the OS needs to support simultaneous reads/writes to the same file. I guess their caching of the file pointer is flakey.