From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wayne Harris via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: why is my cd command on eshell on Windows so slow? Date: Fri, 16 Apr 2021 15:40:29 -0300 Message-ID: <86r1jaqdia.fsf@protonmail.com> Reply-To: Wayne Harris Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22646"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:JV8q7OhIRsu03qBckGCeyi7gUok= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 16 20:41:28 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXTPD-0005me-JQ for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 16 Apr 2021 20:41:27 +0200 Original-Received: from localhost ([::1]:46522 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXTPC-00052X-Gr for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 16 Apr 2021 14:41:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXTOe-00051g-TN for help-gnu-emacs@gnu.org; Fri, 16 Apr 2021 14:40:54 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:33182) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXTOZ-00019s-VE for help-gnu-emacs@gnu.org; Fri, 16 Apr 2021 14:40:49 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lXTOS-0004s4-KS for help-gnu-emacs@gnu.org; Fri, 16 Apr 2021 20:40:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:129009 Archived-At: This problem has to do either with eshell on GNU Emacs 27.1 or with Windows and eshell on GNU Emacs 27.1. I say this because I don't see the same behavior with eshell on GNU Emacs 24.3. (The cd command on eshell on GNU Emacs 24.3 is pretty fast.) But let's see what happens on GNU Emacs 27.1. Thinking it could somehow be the command itself, I uselessly created this following alias: %alias | grep 'cd time' alias cd time cd $* % So when I cd into a directory, I get: %cd dir/ 0.001 secs % However, it actually took about 3 seconds for me to get my prompt back. There is something before cd actually operates (or afterwards) that makes me wait --- *sometimes*. If I immediately ``cd ..'' and then cd into dir/ once again, it's pretty fast. %which cd eshell/cd is a compiled Lisp function in `em-dirs.el' % Can you point me in the right direction? This is a Windows system. I would love to fix this delay. It is not too infrequent and it is correlated to directories infrequently acessed. Thank you! (*) One thing I tried I tried (setq w32-get-true-file-attributes nil) given its documentation (below), but I see no difference. (Notice I don't set this variable on my GNU Emacs 24.3 and I don't see any slow down at all.) --8<---------------cut here---------------start------------->8--- w32-get-true-file-attributes is a variable defined in ‘C source code’. Its value is nil Documentation: Non-nil means determine accurate file attributes in ‘file-attributes’. This option controls whether to issue additional system calls to determine accurate link counts, file type, and ownership information. It is more useful for files on NTFS volumes, where hard links and file security are supported, than on volumes of the FAT family. Without these system calls, link count will always be reported as 1 and file ownership will be attributed to the current user. The default value ‘local’ means only issue these system calls for files on local fixed drives. A value of nil means never issue them. Any other non-nil value means do this even on remote and removable drives where the performance impact may be noticeable even on modern hardware. --8<---------------cut here---------------end--------------->8---