[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optional argument for `file-local-copy'

From: Michael Albinus
Subject: Re: Optional argument for `file-local-copy'
Date: Sun, 14 Dec 2014 11:22:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Stefan Monnier <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]