From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows) Date: Thu, 09 Jul 2009 22:11:19 +0300 Message-ID: <831vopzn6w.fsf@gnu.org> References: <7dbe73ed0907051401o26903ca3t9a67060f3a3417ad@mail.gmail.com> <83fxda1pef.fsf@gnu.org> <7dbe73ed0907060038w53699f77ie742996955ae8118@mail.gmail.com> <838wj11sz4.fsf@gnu.org> <83my7fz09s.fsf@gnu.org> <7dbe73ed0907081347q12dfd1a2lbbff915c49362f75@mail.gmail.com> <4A55D68D.8050407@gnu.org> <7dbe73ed0907090453s3e125b4ar142b90a268b105e2@mail.gmail.com> <7DAFC004A33C486A9E29A59689E7F02E@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1247167096 3495 80.91.229.12 (9 Jul 2009 19:18:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jul 2009 19:18:16 +0000 (UTC) Cc: jasonr@gnu.org, emacs-devel@gnu.org, mathias.dahl@gmail.com To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 09 21:18:08 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MOz7o-0000sG-Ra for ged-emacs-devel@m.gmane.org; Thu, 09 Jul 2009 21:17:45 +0200 Original-Received: from localhost ([127.0.0.1]:57970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOz7n-00034D-Vs for ged-emacs-devel@m.gmane.org; Thu, 09 Jul 2009 15:17:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOz1i-0000C2-OJ for emacs-devel@gnu.org; Thu, 09 Jul 2009 15:11:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOz1g-0000BX-Qg for emacs-devel@gnu.org; Thu, 09 Jul 2009 15:11:25 -0400 Original-Received: from [199.232.76.173] (port=42183 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOz1g-0000BU-L8 for emacs-devel@gnu.org; Thu, 09 Jul 2009 15:11:24 -0400 Original-Received: from mtaout4.012.net.il ([84.95.2.10]:13358 helo=mtaout3.012.net.il) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOz1c-0005nV-Vb; Thu, 09 Jul 2009 15:11:21 -0400 Original-Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KMJ007003P73I00@i_mtaout3.012.net.il>; Thu, 09 Jul 2009 22:11:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.249.41]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KMJ005JS3YUX470@i_mtaout3.012.net.il>; Thu, 09 Jul 2009 22:11:19 +0300 (IDT) In-reply-to: <7DAFC004A33C486A9E29A59689E7F02E@us.oracle.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:112253 Archived-At: > From: "Drew Adams" > Cc: "'Eli Zaretskii'" , > Date: Thu, 9 Jul 2009 09:11:10 -0700 > > Dumb question: Is there a way for Emacs to know whether the format is NTFS or > FAT(32)? Yes (and it does). > If so, then Emacs could use nil for FAT volumes. Doing that by default is too radical, IMO. Having this option non-nil on FAT/FAT32/XFAT has its merits, although less so than on NTFS. And the speedup for local drives would be minimal. > (If not, it seems like nil would be the best default value.) I prefer to carry out a plan I have for speeding up the emulated `stat' so that it works faster without sacrificing features. Those features are important for important use-cases, such as support for files and directories that are private to the user (inaccessible by other Windows users). Note that the slow-down due to additional functionality is only acutely visible when we call file-attributes on long lists of files, like when it is called from directory-files-and-attributes. A single call to file-attributes for a single file is very fast even for networked drives. I think nil should be the last resort, for those pathological cases where disk access is dog slow no matter what you do. Setting the option to nil by default would punish too many use-cases for now good reason.