Re: tramp (2.1.15); Unclear doc for rsync method

[Michael Albinus]

Kai Großjohann <address@hidden> writes:

> It's sad, really, I think.  Only saving a file can take advantage of
> the speedup, and only if some variables are set correctly.  We could
> speed up C-x C-f sometimes if Tramp were to keep a local cache of
> remote files.  Then we could use the cache to "prime" the transfer (by
> copying the cached file to the temporary file, then using rsync to
> update that temporary file).  I think this should be doable within the
> Emacs framework.
>
> We could speed up C-x C-s if we could hook into the saving procedure,
> and after renaming foo to its backup foo~, we would then copy foo~
> back to foo before using rsync to update its content from the local
> copy.  I am afraid this might not be doable within the Emacs
> framework.
>
> I wonder if this is worth the effort or not.  This would only help
> people who use Tramp to edit large remote files on a routinely basis.
> Tramp is somewhat optimized for the small-files case (by its inline
> transfer methods, which are required for multiple hops (unless Michael
> changed this)).

I'm not confident that we shall go this direction. There is currently
another discussion about cached file *attributes*, which run out of
date, when another process on the remote machine changes a file there. I
fear, we couldn't keep local file caches in sync without serious
supervision of changes on the remote side, etc.

rsync could show its advantages, if there would be a special handling
inside Tramp. This includes changed implementation for recursive copying
of directories.

However, both proposal (local cache of files, recursive copying) are
already part of the todo list. I do not plan to work on it next time,
but I'm open to review patches :-)

And maybe somebody has a better wording for the info pages ...

> Kai

Best regards, Michael.