From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: testing for a remote file to include file on a Windows mapped drive Date: Mon, 21 Apr 2008 09:46:48 +0200 Message-ID: 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1208763978 9526 80.91.229.12 (21 Apr 2008 07:46:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2008 07:46:18 +0000 (UTC) Cc: 'Emacs-Devel' , 'Michael Albinus' , 'Stefan Monnier' , 'Jason Rumney' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 09:46:51 2008 connect(): Connection refused 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 1JnqjZ-0004vA-8O for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 09:46:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jnqit-0000CY-OF for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 03:45:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jnqio-0000Bc-5x for emacs-devel@gnu.org; Mon, 21 Apr 2008 03:45:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jnqil-0000BM-S8 for emacs-devel@gnu.org; Mon, 21 Apr 2008 03:45:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jnqil-0000BJ-KR for emacs-devel@gnu.org; Mon, 21 Apr 2008 03:45:51 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jnqig-00020K-7A; Mon, 21 Apr 2008 03:45:46 -0400 Original-Received: from mailrelay1.alcatel.de ([194.113.59.95]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jnqia-0002BL-U6; Mon, 21 Apr 2008 03:45:41 -0400 Original-Received: from slbhab.alcatel.de (slbhab.bln.sel.alcatel.de [149.204.63.218]) by mailrelay1.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id m3L7jXVJ032394; Mon, 21 Apr 2008 09:45:33 +0200 In-Reply-To: <000101c8a37f$eeb543d0$0200a8c0@us.oracle.com> (Drew Adams's message of "Mon, 21 Apr 2008 00:18:43 -0700") User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (hpux) X-Scanned-By: MIMEDefang 2.57 on 149.204.45.72 X-detected-kernel: by mx20.gnu.org: Linux 2.6, seldom 2.4 (older, 2) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:95603 Archived-At: "Drew Adams" writes: > 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. > > * A file on a Windows mapped network drive is remote, in the sense of incurring > a performance penalty for access. `file-remote-p' should return non-nil for such > a file, but nil for a file on a Windows local drive. That is not the case now. I believe, we are speaking about 2 different functions: * file-remote-p returns t, if a file is not directly accessible by underlying operating system's means. Such files always need some special file name handler functions in Emacs for proper handling. Such (absolute) file names cannot be used literally outside functions, which support file name handlers. * file-mounted-p (as working name) returns t, if a file looks like an ordinary file from the operating system's point of view, but its physical location is on another machine. Examples are nfs, smbfs or sshfs mounts under GNU/Linux, or network shares under W32. This property cannot be detected by file name handler functions. The implementation shall be in the C core. These functions are exclusive: file-remote-p and file-mounted-p shall not return t for the same filename. Since one function uses the filename only for checking the result, and the other function uses operating system properties, I don't believe it makes sense to merge them into one function. A test for "slow access" is therefore (or (file-mounted-p filename) (file-remote-p filename)) > [Apologies, Michael, for quoting off-list mail; I assumed you wouldn't mind.] No problem, you can always quote me, unless I've stated otherwise. > So if ffap-ftp-regexp is subsumed by an ange-ftp test, the question becomes > whether that ange-ftp test should be included in `file-remote-p'. ??? The relevant test for ange-ftp is included in file-remote-p. Best regards, Michael.