Date: Mon, 6 Aug 2001 15:06:19 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andrew Cottrell <acottrel AT ihug DOT com DOT au>
cc: Charles Sandmann <sandmann AT clio DOT rice DOT edu>, djgpp-workers AT delorie DOT com
Subject: Re: Windows 2000 /dev/null permission query
In-Reply-To: <00ce01c11e6c$5858cb40$0a02a8c0@acceleron>
Message-ID: <Pine.SUN.3.91.1010806145606.25573D-100000@is>
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 Mon, 6 Aug 2001, Andrew Cottrell wrote:

> > > 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?
> DJGPP_204 D:\dj204\contrib\touch>set LFN=y
> 
> DJGPP_204 D:\dj204\contrib\touch>ls -l nul
> -rw-r--r--   1 AC       root            0 Jan  1  1980 nul

Darn!  So findfirst is also broken in its LFN version: it doesn't set 
the device bit in the attribute byte.  This means that a few more 
functions in the library will probably fail, like `access', when invoked 
on NUL and other devices.

> DJGPP_204 D:\dj204\contrib\touch>ls -l NUL
> crw-r--r--   1 AC       root       0,   0 Aug  6 21:30 NUL>
> 
> I can't rememebr my Ui*x days to decode the 'c' in the permissions feilds.

That's the sign of a character device.  It means that the non-LFN version 
of findfirst is emulated correctly.

> Some interesting diffreences:
>     1) check out the times as the last one was when I ran the ls command.
>     2) The ls with LFN=n has an extra 0, in the line

These are both consequences of the fact that NUL is not reported as a 
character device by findfirst.  For character devices, "ls -l" prints 
the major and minor fields of st_rdev, but since W2K reports NUL as a 
regular files, `ls' prints its size instead.  Similar things happen with 
the date: for devices, `stat' reports the current time there, whereas for 
regular files, it reports whatever findfirst returns.

In other words, these are not additional problems, but consequences of 
the original one: NUL is not reported as a device.

> > > 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.)
> >
> What's next?

I'd say let's find a solution for this problem first, before moving to 
others.  See my other mail about possible avenues of approach.