Why is stat slow?

[Eliot Moss]

On 12/22/2025 8:57 AM, Jakob Bohm via Cygwin wrote:

> As a longtime aficionado of these issues, Cygwin/MSYS2 stat() function is
> inherently slower than native Linux/WSL stat() syscall, because the native
> stat returns data already kept and cached for each file system inode/MFTE,
> while the Cygwin emulation goes through a lot of hoops to synthesize similar
> information from a variety of file system data .  The call path that uses
> GetFileInformationByHandle() is the closest to a native fast implementation,
> but unfortunately, most 21st century antivirus solutions tend to initiate a
> full "scan file on open to prevent passing infected data to vulnerable
> applications" cost when doing the proforma file open to get the file handle
> needed for the GetFileInformationByHandle() call or other low risk checks .

> Another set of hoops in the stat() code is the synthesis of a simulated set
> of mode bits, which tends to bring in the entire ACL reinterpretation logic
> as well as detection of various symlink approximations (it would be faster
> to simply treat all "reparse points" as symlinks and add logic to readlink()
> that deals with the various native types, but that would loose the ability
> to create file system symlinks without the Administrator privilege of
> creating the more dangerous system objects also named "symlink" ).

> If the false triggering of AV scanning can be avoided, streamlining the
> Cygwin stat() code could greatly speed up heavy users of stat() such as the
> find and du commands .

Thank you, Jakob!  That gives me some interesting ideas.  First, one of my
mount lines indicates noacl, so I may be avoiding that cost.  (I am still a
little confused about having two mount lines and wonder which one takes
precedence (or some combination?).)  Concerning antivirus, maybe I can turn it
off for that drive.  It stores only tings I explicitly put there, which should
not need scanning for safety.

Regards - Eliot