Question about slow access to file information

[gs-cygwin.com@gluelogic.com]

On Sun, Jan 15, 2023 at 12:05:10PM +1100, Eliot Moss via Cygwin wrote:
> On 1/15/2023 3:38 AM, Christian Franke via Cygwin wrote:
> > Eliot Moss via Cygwin wrote:
> > > I have a separate drive mounted this way:
> > > 
> > > d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
> > > 
> > > One thing I use it for is to store backup files.  These tend to be 2 Gb
> > > chunks, and there can be hundreds of them in the backup directory. (The drive
> > > is 5Tb.)  The Windows Disk Management tool describes it as NTFS, Basic Data
> > > Partition.
> > > 
> > > Doing ls (for example) takes a very perceptible numbers of seconds (though
> > > whatever takes a long time seems to be cached, at least for a while, since a
> > > second ls soon after is fast).
> > 
> > The problem is the 'noacl' mount option and the fact that POSIX only
> > offers the *stat*() functions to retrieve file information. These
> > functions always need to provide the full file information, even if only
> > a small subset is needed.
> > 
> > To determine the 'x'-permission bits in the 'stat.st_mode' field on a
> > 'noacl'-mount, Cygwin reads the first bytes of most files (all except
> > *.exe, *.lnk, *.com). The 'x' bits are set if the file starts with "#!"
> > (script), ":\n" (?) or "MZ" (Windows executable).
> > 
> > On 'noacl' mounts, this behavior could be suppressed by 'exec' or 'noexec' mount options.
> 
> Interesting.  I removed the noacl from /etc/fstab and restarted all Cygwin processes.
> The mount program now shows that drive without noacl.  It still takes surprisingly
> long to ls if I have not done so recently.  The directory contains ~1200 files.
> 
> Further thoughts?

Does this make any difference?
$ env - LANG=C ls -f /cygdrive/d/

Also, ISTR prior mailing list postings on how cygwin may open() each
file to determine some info, and that can be expensive.  Is that what is
happening if you trace the 'ls'?

Cheers, Glenn