Date: Mon, 6 Aug 2001 09:46:24 +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: Windows 2000 /dev/null permission query In-Reply-To: <10108052205.AA12321@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, 5 Aug 2001, Charles Sandmann wrote: > OK. More info here, and you are not going to like it :-P You are right: I don't like it ;-) > I added a call to _get_dev_info for NUL - and it returns 0, it's not > a character device ... Does "ls -l NUL" say that it's a character device? > (don't you love Win 2k?) I'm warming up... > Now, thinking about the other problems we had noticed, I then did a > set lfn=n ... > > Now, the write of zero bytes to NUL works fine. And _get_dev_info > returns lots of bits (but I don't need them now...) > > Touch a.a works with lfn=n but fails with lfn not set. > > Conclusion - LFN support in W2K is breaking things (like truncate, > utime, get_dev_info). Handles opened with the LFN calls are not being > treated the same as those opened with the old DOS APIs. This might mean we need an exhaustive sweep of all the handle-related DOS calls, to see whether more of them are broken on W2K. In particular, those Int 21h file-related functions used by the library should be all checked. (The bugs are probably due to the fact that LFN was added to W2K as a hindsight, unlike Windows 9X where it is simply a real-mode entry into Windows's own file-handling routines implemented around PM Int 21h.)