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: Mon, 21 Apr 2008 22:29:25 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Content-Transfer-Encoding: 7BIT X-Trace: ger.gmane.org 1208806271 20202 80.91.229.12 (21 Apr 2008 19:31:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2008 19:31:11 +0000 (UTC) Cc: jasonr@gnu.org, michael.albinus@gmx.de, monnier@iro.umontreal.ca, drew.adams@oracle.com, emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 21:31:42 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 1Jo1j2-0004IE-Iu for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 21:31:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jo1iB-0004UZ-AX for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 15:29:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jo1i5-0004UG-Uq for emacs-devel@gnu.org; Mon, 21 Apr 2008 15:29:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jo1hv-0004Sk-Cz for emacs-devel@gnu.org; Mon, 21 Apr 2008 15:29:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jo1hv-0004Sg-6E for emacs-devel@gnu.org; Mon, 21 Apr 2008 15:29:43 -0400 Original-Received: from mtaout1.012.net.il ([84.95.2.1]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jo1hj-0008Kl-8K; Mon, 21 Apr 2008 15:29:32 -0400 Original-Received: from HOME-C4E4A596F7 ([83.130.1.82]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0JZO00GMWXGKH9N1@i-mtaout1.012.net.il>; Mon, 21 Apr 2008 22:43:33 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-kernel: 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:95679 Archived-At: > From: Michael Albinus > Date: Mon, 21 Apr 2008 09:46:48 +0200 > Cc: 'Emacs-Devel' , > 'Michael Albinus' , > 'Stefan Monnier' , > 'Jason Rumney' > > 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. 110% agreement. And, given several good arguments posted by Andreas, it sounds like the best implementation for determining whether accessing a file is likely to be slow would be a simple alist, set by the user, since only the user knows which filesystems on her machine cause slowdown. I don't see how Emacs can determine that by itself without actually accessing the file.