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

[Michael Albinus <michael.albinus@gmx.de>]

Stefan Monnier <monnier@iro.umontreal.ca> 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.