Re: Remote display-time-mail-file

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

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, this fixes the problem, thanks.
>
> So what are the triggers for Tramp to refresh its cache?  Does every
> function which deal with files that can be modified behind Emacs's
> back need to bind tramp-cache-inhibit-cache to a non-nil value?

Until now, we have only the variable `process-file-side-effects'. When
non-nil, a call of `process-file' is expected to modify files out of
Emacs' control, and packages like Tramp must invalidate the respective
file attributes cache. The default value is t (any process might have
side effects); it could be let-bound to nil in case one knows there
aren't side effects for a given process call.

Apart from this, we have no general mechanism to indicate that files
could have changed. We could introduce a similar variable
`remote-file-side-effects' (tell me a better name, if you know), which
does it say in general. It's default value shall be nil, but in cases
file attributes caches hurt (like in your example), one could let-bind
it to t.

I wouldn't recommend to disable Tramp's file attributes cache at
all. There are serious performance improvements, using the cache.

Best regards, Michael.