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: testing for a remote file to include file on a Windows mapped drive Date: Sat, 26 Jan 2008 20:58:42 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1201373934 12822 80.91.229.12 (26 Jan 2008 18:58:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jan 2008 18:58:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 26 19:59:14 2008 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 1JIqFD-0004ub-KG for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2008 19:59:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIqEn-0000gL-BJ for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2008 13:58:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JIqEj-0000fh-Mv for emacs-devel@gnu.org; Sat, 26 Jan 2008 13:58:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JIqEh-0000eh-5e for emacs-devel@gnu.org; Sat, 26 Jan 2008 13:58:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIqEg-0000eZ-UJ for emacs-devel@gnu.org; Sat, 26 Jan 2008 13:58:38 -0500 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JIqEg-0007yw-DS for emacs-devel@gnu.org; Sat, 26 Jan 2008 13:58:38 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-218-76.inter.net.il [83.130.218.76]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id KAP52131 (AUTH halo1); Sat, 26 Jan 2008 20:58:17 +0200 (IST) In-reply-to: X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:87591 Archived-At: > From: "Drew Adams" > Cc: > Date: Sat, 26 Jan 2008 09:57:17 -0800 > > > Accessing a remote file via the normal filesystem API (which is what > > happens with remote drives and NFS-mounted volumes) is several orders > > of magnitude faster than Tramp or ange-ftp. So I find it hard to > > believe that the same primitive would fulfill both of these needs. > > I didn't say anything about using "the same primitive". Well, you repeatedly talked about file-remote-p, so it's easy to err like I did. Sorry. > Perhaps the performance depends also on the particular remote machine and > its connectivity, VPN, firewall, etc. I don't know, and I don't care. For > me, it does no good to argue that accessing a mapped network drive is > "several orders of magnitude" faster than using Tramp or FTP. It is not > *noticeably* faster in my case, and, more importantly, it is much, much > slower for me than accessing a local file. No numbers; only perception. It > might be orders of magnitude faster, but it is too slow for me. > > Trust me - If a file name is likely to represent a file that is on a network > drive, then I usually want to treat it as the name of a remote file in terms > of avoiding unnecessary access. That's all. You seem to perceive my questions as some kind of questioning the validity of your reports. That is a far cry from what I meant. If this problem is something specific to your setup, you could devise your own private solution: after all, you likely know what drives are connected to remote machines in your case. (Btw, you never responded to my suggestion to try the output of "net use".) But if you are asking for an Emacs primitive to solve this, then please do at least some research and provide the details and quantitative results about the problem. At the very least, those numbers will be used when various possible solutions are evaluated by those who might work on this problem, as the baseline to measure the speedup of those solutions. It is also quite probable that we will want to compare your results with ours, as we try to find the reason(s) for the slowdown. "Trust me" will not help us do that. While you might not care about the reasons, we who maintain the Windows port surely do care, because without understanding those reasons, we cannot devise the right solution. For example, while you think that the reason is the fact that these files are on a remote machine, the real reason might be something entirely different, in which case the GetDriveType call is not going to solve the problem for you.