Re: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

X-seq: zsh-workers 50279

From: Stefan Radziuk <sradziuk@xxxxxxxxxxxxxxx>

Cc: "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>

Subject: Re: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

Date: Mon, 23 May 2022 11:32:08 +0000

Accept-language: en-US

Arc-authentication-results: i=2; mx.microsoft.com 1; spf=fail (sender ip is 199.20.13.32) smtp.rcpttodomain=zsh.org smtp.mailfrom=pdtpartners.com; dmarc=fail (p=none sp=none pct=100) action=none header.from=pdtpartners.com; dkim=fail (body hash did not verify) header.d=pdtpartners.com; arc=fail (47)

Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pdtpartners.com; dmarc=pass action=none header.from=pdtpartners.com; dkim=pass header.d=pdtpartners.com; arc=none

Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GgQhW9ZPaHvT3D85Hq9Gh5GzzneOHu64evtjLzOd/xQ=; b=cm02Ea9js4zrEJhhi9AgYW2eLN1YnDJ3H1fGQ6WxDWSTKl8t8ucdyqI89LHDXo7Lamu74hhUHOhXTHHC5UvlVYB5IfGicbp/aYMn6aOFiKxDlNIcpZ2WeO0uERBJE9s1Gupth2CdiZVBKl1BKJ93h4Di+sbrNxiWwWB0mqlolSlDo6uDj2aS7tHfq2qR4Uz8iFI5bVKhXebSabHtdK+1daJMruj8PzEz+MQ3cllbucgrnfwCQxSupgCQUaVJ18JXPx6devNeDZs5U0oP651aezproKKRTtuu9TpgXQLLC554FVlEz7R6fAi2sMpR5vtQ25MCmYzKIPS9xZj2bORDVg==

Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JhGEYHaFblR6m+kTdP+m8osqOFTgbU5Y6ttpjvHsSbA=; b=Wg/yTbBiF4tR1kDH82+ei98PaaSWCnqkoSbIC4QWz128MXGW3w3JTQLcsPJq7biuO80SpmxEjFWTlyIxd6fdba9f95oag9BfhE38EVCF3gM4m1VHd5vAn9CBwpc5rrglZpQD0tOr1oRwrj5euUJHm+p+y9mbQOv50if6Yv5pjM2B5mFE9Iq5uixSn/nhAMajWKMg1bsq60Xom2fOhzFoEzPQeNfS32IGLTLqda1AocM8rk0O0SR8c2t6p2QnY/dZEFCPjujI9apMX/qZlL/77SmKu7uAmamqHtWk8vEfcX/JrdgKXhajy+ZZG/pFT8LxIpLMOeuOM+Hw58hHnJIQUA==

Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=fail; b=cyJWLLzUmyKeRnIN4QTqOeQRJe8y1icBBKfYGs99r4o9tD62+E0fyS6iT88adyCJoKQrOpHKVkvddEQKTH5yIFiRNP6c0UdjQKV4f1IJRrWHhSx0n3v8XpC9GAfFnBZw7b1cLPTi3vE7mC1JYO92NI5a/zt2pzQw65oTE66vzhfZTD6E2dQvz//B1tZviU20W32LpoFhE9uDk4TazxP+6RaNw7/kLHDgCOW5e5jF/cTBZ2zAZF1nqqMTZjltQdyYauMt8WYrvaSv6yMH3z8juPea0K5+3hzIP28+hOSC08xcUnXZj+/SADLdQLu0eboahfOQ0kkwCbNOQNR3Gv+ldw==

Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g6WxZ9Dkw2xJQg8Wedb2eynQ2R6A9mEBctMCuB60PFn5TxgdbOnH/e2DkpMCWfH0hC1N5igAiPKIc4+LTi6X0bkMJF1Dm6B7z+Lrr/ICXvAV26ilSsK3uSFAimSvGIgfDMzAyJTOcGBGROINB9Kq4VqR0WOGAKphm92iKVT1kbyBqlmXJ506CGPTgy0mWqvZPKXVJRlHEofGyYdkKNlkIzQVDFUkvzYlLp69jD8C6mbvbnd+lvgWbCsgpCHzlOUiK5Oq4m9eOayV8XfQO1k/zl3O82gdG34qw/wCGFZ7NaB+eJQXlW5vIySRJB3qw9yNeqcfhV5QhLjwWQOnuljZdQ==

Archived-at: <https://zsh.org/workers/50279>

In-reply-to: <CAHYJk3QTi9f7h92HkAZbOGkQ9nqVNGJFByJrBDN6C-W7+CYm4Q@mail.gmail.com>

List-id: <zsh-workers.zsh.org>

References: <CY5PR20MB4843E231D8BA513A209C6541C1D39@CY5PR20MB4843.namprd20.prod.outlook.com> <CAHYJk3QTi9f7h92HkAZbOGkQ9nqVNGJFByJrBDN6C-W7+CYm4Q@mail.gmail.com>

Thread-index: AQHYbDEPYF0J/kRF40qfVUNFCmBzxq0nkhcAgATF5Ik=

Thread-topic: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

> Do you get the same results with :P ? :a and :A are not guaranteed to
> result in a path leading to the same file (eg, symlink/../ will be
> simply deleted without following the symlink etc)

Yes, running with strace confirms that :a,A,Pall exhibit the same lstatting behaviour (they all call zgetcwd).

From: Mikael Magnusson <mikachu@xxxxxxxxx>
Date: Friday, May 20, 2022 at 11:35 AM
To: Stefan Radziuk <sradziuk@xxxxxxxxxxxxxxx>
Cc: zsh-workers@xxxxxxx <zsh-workers@xxxxxxx>
Subject: (EXT) Re: Using the history expansion modifier 'a' results in excessive lstat calls

On 5/20/22, Stefan Radziuk <sradziuk@xxxxxxxxxxxxxxx> wrote:
> zsh uses zgetdir to evaluate ${FOO:a}. When in a directory in a different
> filesystem to its parent, zgetdir will lstat many entries in the parent.
> This leads to slowness, especially when some of the lstatted entries are on
> remote filesystems.
>
>
>
> This behaviour can be avoided by making zsh use getcwd instead (build zsh
> with USE_GETCWD). Interestingly, getcwd will also be used in the regular zsh
> build if zgetdir fails (see the implementation of zgetcwd).
>
>
>
> I have looked through some threads in the mailing list to find out why
> zgetdir is being used over getcwd in the first place. It seems it was
> implemented this way in the 1990s to work around a bug in some
> implementations of getcwd, which should not be a concern on modern systems.
>
>
>
> I was wondering if zgetdir is still the right way to do this? Are there use
> cases where it is preferred over getcwd? Maybe zgetcwd could simply use
> getcwd primarily (i.e. not as fallback), or perhaps USE_GETCWD could be
> enabled by default (currently it is only enabled on QNX builds).

Do you get the same results with :P ? :a and :A are not guaranteed to
result in a path leading to the same file (eg, symlink/../ will be
simply deleted without following the symlink etc)

--
Mikael Magnusson

This communication is intended only for the addressee(s), may contain confidential, privileged or proprietary information, and may be protected by US and other laws. Your acceptance of this communication constitutes your agreement to keep confidential all the confidential information contained in this communication, as well as any information derived by you from the confidential information contained in this communication. We do not waive any confidentiality by misdelivery.

If you receive this communication in error, any use, dissemination, printing or copying is strictly prohibited; please destroy all electronic and paper copies and notify the sender immediately. Nothing in this email is intended to constitute (1) investment or trading advice or recommendations or any advertisement or (2) a solicitation of an investment in any jurisdiction in which such a solicitation would be unlawful.

Please note that PDT Partners UK, LLP, including its affiliates, reserves the right to intercept, archive, monitor and review all communications to and from its network.

Reverse Date

Date

Thread

Author