From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: testing for a remote file to include file on a Windows mapped drive Date: Mon, 21 Apr 2008 10:08:10 -0700 Message-ID: <001501c8a3d2$47015b30$c2b22382@us.oracle.com> References: <87bq781bf7.fsf@gmx.de><000a01c8a314$5fff7630$0200a8c0@us.oracle.com><000d01c8a324$97820590$0200a8c0@us.oracle.com><000f01c8a334$b2a40660$0200a8c0@us.oracle.com><000101c8a37f$eeb543d0$0200a8c0@us.oracle.com> <480C4220.3030100@gnu.org> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1208798053 16516 80.91.229.10 (21 Apr 2008 17:14:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2008 17:14:13 +0000 (UTC) Cc: 'Michael Albinus' , 'Stefan Monnier' , 'Emacs-Devel' To: "'Jason Rumney'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 19:33:20 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1Jnzt3-0003nr-42 for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 19:33:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnzWB-0002Az-6w for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 13:09:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JnzW7-0002Ag-M4 for emacs-devel@gnu.org; Mon, 21 Apr 2008 13:09:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JnzW1-00029b-PO for emacs-devel@gnu.org; Mon, 21 Apr 2008 13:09:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnzW1-00029Y-JV for emacs-devel@gnu.org; Mon, 21 Apr 2008 13:09:17 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JnzVk-000153-Ou; Mon, 21 Apr 2008 13:09:04 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m3LH8Y3d013796; Mon, 21 Apr 2008 11:08:34 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m3K7b8Gp026864; Mon, 21 Apr 2008 11:08:33 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3655692911208797689; Mon, 21 Apr 2008 10:08:09 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Apr 2008 10:08:09 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <480C4220.3030100@gnu.org> Thread-Index: AcijgWrrMrIg/trxR4Cujv1K4aFBjgATkQ4Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:95653 Archived-At: > > As you said, the purpose of file-remote-p is to determine, > > without the cost of a remote access, whether a file name > > represents a remote file. The aim in using it is to be able > > to know that a file is remote, so you might then avoid the > > cost of accessing it. > > > > As mentioned in the earlier thread, remoteness is not a reliable > indicator of speed. You can have fast remote drives and slow local > drives. Maybe in the days of 10Mbps ethernet it was still > reasonable to > assume that networked drives were slow, but with gigabit > ethernet you'd > be hard pressed to notice a performance difference between a > networked > and local drive. See my reply to your other mail. Regardless of where it is and what is called, we need some quick estimate of whether accessing a file will be relatively fast or slow. And the purpose of file-remote-p was decided (in the earlier thread) to be as I said above: to give a quick estimate with the aim of being able to avoid a performance penalty. IOW, as long as we don't have other functions to do that, `file-remote-p' is the place to do it. I have no objection to renaming things or adding another function that takes other things into account. My aim is the stated aim of file-remote-p (as decided in the earlier thread): to avoid trying to access (e.g. match name against existing files) files when that access might be slow. I need at least a binary determination: fast vs slow.