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: Optional argument for `file-local-copy' Date: Tue, 02 Dec 2014 09:18:41 -0500 Message-ID: References: <871tom5jou.fsf@gmx.de> <83bnnqb1lo.fsf@gnu.org> <20141129140856.GA3752@acm.acm> <83a93aax58.fsf@gnu.org> <20141129153320.GC3752@acm.acm> <87d2853q5i.fsf@gmx.de> <87k32cbo06.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417529961 15595 80.91.229.3 (2 Dec 2014 14:19:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Dec 2014 14:19:21 +0000 (UTC) Cc: Alan Mackenzie , Eli Zaretskii , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 02 15:19:14 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XvoIL-0006BG-S7 for ged-emacs-devel@m.gmane.org; Tue, 02 Dec 2014 15:19:14 +0100 Original-Received: from localhost ([::1]:37085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvoIL-00016c-Au for ged-emacs-devel@m.gmane.org; Tue, 02 Dec 2014 09:19:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvoIB-00016E-JV for emacs-devel@gnu.org; Tue, 02 Dec 2014 09:19:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvoI4-00050k-4d for emacs-devel@gnu.org; Tue, 02 Dec 2014 09:19:03 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:28418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvoHw-0004yu-14; Tue, 02 Dec 2014 09:18:48 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUIAGA2ZVRMCqTq/2dsb2JhbABbgw6KYssMBAICgRwXAQEBAQEBfIQDAQEDAVYjBQsLNBIUGA0kiEsJ0QQBAQEHAQEBAR6RFAeESwWMC6cXgXaEGh+CewEBAQ X-IPAS-Result: AsUIAGA2ZVRMCqTq/2dsb2JhbABbgw6KYssMBAICgRwXAQEBAQEBfIQDAQEDAVYjBQsLNBIUGA0kiEsJ0QQBAQEHAQEBAR6RFAeESwWMC6cXgXaEGh+CewEBAQ X-IronPort-AV: E=Sophos;i="5.07,380,1413259200"; d="scan'208";a="99357738" Original-Received: from 76-10-164-234.dsl.teksavvy.com (HELO pastel.home) ([76.10.164.234]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 09:18:47 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 02D8143C3; Tue, 2 Dec 2014 09:18:41 -0500 (EST) In-Reply-To: <87k32cbo06.fsf@gmx.de> (Michael Albinus's message of "Sun, 30 Nov 2014 18:24:09 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178683 Archived-At: >> Thanks for getting us back on track. Yes, I agree with adding such >> a functionality. But I have the impression that it's not enough: if the >> caller doesn't know whether the file is indeed being cached or not, then >> it doesn't know whether to delete it or not once it's done using it. > The caller does not need to know whether a file is cached. File name > handlers implementation shall keep *always* the information about a > local copy of a remote file (the local name, the result of > file-attributes of the remote file). That means that the file-local-copy handlers *always* have to obey REUSE-IF-ALREADY-EXISTS, rather only doing so if they use a cache. > A problem might be to remove local copies when they are not > used anymore. That's inherent in the use of a cache, I'm not too worried about that, tho of course, we'll have to make it work well (erasing at the end of the session is problematic since the session might not end cleanly, so we'll probably want to instead make the cache survive for longer, and share it across sessions). Stefan