DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5BME5q9M672020
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E3E7B4BA2E32
Message-ID: <f58b6ae4-1ba2-31cb-13ed-5ea1c63e0e4a@cs.umass.edu>
Date: Mon, 22 Dec 2025 09:05:27 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: Why is stat slow?
Content-Language: en-US
To: Jakob Bohm <jb-cygwin@wisemo.com>, cygwin@cygwin.com
References: <74bdc787-9099-8e29-492a-588546b6eedb@cs.umass.edu>
 <459d4abb-14fe-af09-f62d-defe3454e2c3@wisemo.com>
In-Reply-To: <459d4abb-14fe-af09-f62d-defe3454e2c3@wisemo.com>
From: Eliot Moss via Cygwin <cygwin@cygwin.com>
Reply-To: Eliot Moss <moss@cs.umass.edu>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

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

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple