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

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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.

Well, it does not need to obey that argument. My idea is that the
*meta information* are always stored.

>> 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).

Yes. This might be mainly problem when the cache is too small on the
file system. Maybe one could restrict the size of the files being
cacheable. But OTOH, very large files profit more from being cached.

Another idea could be to implement a timeout for cached files; after a
given time they are not valid anymore. But that's not needed in the
beginning; I would add some functionality when there's a need from the
users.

>         Stefan

Best regards, Michael.