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: Optional argument for `file-local-copy' Date: Sun, 14 Dec 2014 11:22:40 +0100 Message-ID: <877fxuedjj.fsf@gmx.de> 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> <87k32ahzmt.fsf@gmx.de> <8761dtoidb.fsf@gmx.de> <87iohlhrsx.fsf@gmx.de> <8761dik0f5.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418552601 25290 80.91.229.3 (14 Dec 2014 10:23:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Dec 2014 10:23:21 +0000 (UTC) Cc: Alan Mackenzie , Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 14 11:23:16 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 1Y06KZ-0005Gz-L3 for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 11:23:15 +0100 Original-Received: from localhost ([::1]:35527 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y06KZ-0005MY-6y for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 05:23:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y06KI-0005M1-QA for emacs-devel@gnu.org; Sun, 14 Dec 2014 05:23:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y06KC-0005sg-R4 for emacs-devel@gnu.org; Sun, 14 Dec 2014 05:22:58 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:52871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y06K6-0005s6-67; Sun, 14 Dec 2014 05:22:46 -0500 Original-Received: from detlef.gmx.de ([87.146.33.186]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M1Fe4-1XgNY22hXk-00tCbk; Sun, 14 Dec 2014 11:22:42 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 11 Dec 2014 10:22:11 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:cyO8eypqlg4Dfw9CTxx1ORWDRHKojRTuTIL+VRjexIRmEa/IGum YtWgICUJE5pdWpgO1wugyvELIHdWvTEZhrWj3MwCiN1A2hbwUbpdaEfmZWLPJppnbk0wWv/ 8zKLGLk8rE86DlrbLu6aIUO6JIDZqHinRedMRWlFDrXmFIHL2FcHYatEGW9BVtwS3ztqZJ1 nyVcf4va1H8f7KzY1Rnrg== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.15.18 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:180064 Archived-At: Stefan Monnier writes: > Yes, but how will you write the code so that the temp/cached files > don't linger indefinitely? > > Don't get me wrong: I like the idea, but I think we need to think a bit > more about how to handle the cache and deletion, in order to design the > API correctly. > > Here's the problem I currently see: > - OT1H you currently have the caller as the one responsible for the > deletion of the file. > - OTOH it's the handler that decides where to put the file. > That seems to make it difficult to get a good behavior. E.g. you might > want to keep the file for a long time (across sessions) in a special > "cache" subdirectory somewhere, but this decision can't be made by the > handler (because the caller will have to delete the file without knowing > it's meant to be kept) and it can't be made by the caller either > (because it can't tell the handler where to put the file). Currently, `file-local-copy' keeps the files in `temporary-file-directory'. One could use a subdirectory of that. And I don't know whether such local copies shall be kept over Emacs session boundaries. In the Tramp case, it might be acceptable to remove all local file copies for a given remote host, when the connection to that host is (re-)established. > Maybe a better option is to change the optional argument so that it's > not just a boolean but it's actually the name of a "candidate local > copy" (i.e. it's the name of the local copy kept in the cache managed > by the caller), tho maybe we'd need more info (e.g. the full > file-attributes). The mapping of a remote file name to the local copy could be managed inside the `file-local-copy' machinery. And whether we always need file-attributes I'm not sure. One implementation inside Tramp could be to install a file notifications handler for the remote file if possible. We will be informed then, when the remote file changes, and the local file is out-dated. > Stefan Best regards, Michael.