X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Wed, 16 Jan 2002 18:24:29 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: sandmann AT clio DOT rice DOT edu
Message-Id: <7458-Wed16Jan2002182428+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com
In-reply-to: <10201161548.AA21690@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: ls weirdness on root drive
References:  <10201161548 DOT AA21690 AT clio DOT rice DOT edu>
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

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Wed, 16 Jan 2002 09:48:40 -0600 (CST)
> 
> > If you only see the weird behavior in stat, it could be 
> > something peculiar to lstat, not to findfirst.  stat examines the DOS 
> > attributes, and tries to detect volume lables, so it could err when the 
> > attributes include the volume-label bit (it happened in the past on NT).
> 
> This is an NTFS volume.  It does not have a label.

But the interesting question is, does W2K return the volume bit in the
attribs we get from findfirst?  It could do that even if the
filesystem doesn't store any such bits (recall that the extra
directory entries used by VFAT for long file names have all of the
volume+system+hidden bits set, to force legacy DOS programs which read
the disk directly to skip such entries).

> ls -l and ls -F work (show all normal files)
> ls does not work (shows all regular files and first hidden file; in
>  alphabetical order stops listing when a system file is hit.  example,
>  shows a.a (reg) autoexec.bat(hidden) b.b(reg) bna(dir) stops and does
>  not display boot.ini (system+hidden))

One difference between "ls" and "ls -l" is that the latter resets some
of the flags in _djstat_flags.  When those flags are set, they cause
some of the expensive parts of the code in `lstat' to be skipped, for
efficiency.  Perhaps skipping some of the system calls somehow
triggers a subtle bug?