From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: testing for a remote file to include file on a Windows mappeddrive Date: Sun, 27 Jan 2008 15:43:33 -0500 Message-ID: References: <871w844yff.fsf@gmx.de> <87bq781bf7.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1201467024 32061 80.91.229.12 (27 Jan 2008 20:50:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jan 2008 20:50:24 +0000 (UTC) Cc: Jason Rumney , Drew Adams , Emacs-Devel To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 27 21:50:43 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 1JJESh-0000D6-Cu for ged-emacs-devel@m.gmane.org; Sun, 27 Jan 2008 21:50:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JJESG-0005sF-KA for ged-emacs-devel@m.gmane.org; Sun, 27 Jan 2008 15:50:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JJESC-0005rW-Vt for emacs-devel@gnu.org; Sun, 27 Jan 2008 15:50:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JJESB-0005rH-UT for emacs-devel@gnu.org; Sun, 27 Jan 2008 15:50:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JJESB-0005rE-QL for emacs-devel@gnu.org; Sun, 27 Jan 2008 15:50:11 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JJES7-0008BC-Sw; Sun, 27 Jan 2008 15:50:08 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL99nEfO+J95dGdsb2JhbACQKAEwgSGYQ4EA X-IronPort-AV: E=Sophos;i="4.25,257,1199682000"; d="scan'208";a="13273358" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 27 Jan 2008 15:50:06 -0500 Original-Received: from ceviche.home ([206.248.159.121]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id HVZ09306; Sun, 27 Jan 2008 15:50:06 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id CE3BCB409A; Sun, 27 Jan 2008 15:43:33 -0500 (EST) In-Reply-To: <87bq781bf7.fsf@gmx.de> (Michael Albinus's message of "Sat, 26 Jan 2008 23:15:08 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:87653 Archived-At: >> I suggest we clarify the meaning of file-remote-p to explain that it >> returns info that relates to the time and reliability of the access to >> this file. And we introduce a new one `unhandled-file-name' which >> returns either "an equivalent name that can passed to subprocesses" >> (e.g. for the "/:/" file-name-handler, it just strips the leading "/:" >> and similarly for the "file://" one) or nil if the file cannot be >> directly accessed by a subprocess (either because it's only accessible >> via ssh/ftp/tar/younameit it by a file-name-handler). > At least for remote files I've introduced it silently ... > (file-remote-p "/sudo::/etc" 'localname) returns "/etc". But you are > right, `unhandled-file-name' would be more general but just for Tramp. > But we shall come back to the original request of Drew: he wants to > know whether a given file is "remote", independant of the syntax. > Such information cannot be provided by 'file-remote-p', because that > function has an important promise: "`file-remote-p' will never open > a connection on its own." (from the doc-string). That's indeed a good guaranteed, and I don't see it as an obstacle. After all, if you'd need to contact a remote host to find out, then the object can't be local. > It also doesn't touch a local file; it works completely over the file > name syntax. This promise is important because of performance. It's not promised explicitly, tho I'm not sure what you mean by "touch". In any case, looking at the file's contents can't be of much use. > Rough idea: maybe one could use the device number, returned as last > attribute of `file-attributes', for a check whether a file has been > "mounted". I haven't seen code evaluating the device number. And I > don't know whether it is set to a useful value on W32, for example. I don't think you can get any reliable useful info from the device number. Anyway, any objection to my proposal to clarify file-remote-p's intended semantics, and to add unhandled-file-name (tho maybe it should be called file-local-name, to make it closer to file-local-copy which is kind of its complement)? Stefan