On 04/13/2009 11:56 AM, Michael Albinus wrote:
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.
I think in this case there is not much to worry about, since the worst
case is no speed up in the file transfer.
If you do "rsync $REMOTE_FILE $LOCAL_FILE", and if rsync does not fail,
then you can assume that after the command finishes, $LOCAL_FILE is an
exact copy of $REMOTE_FILE. This assumption holds regardless of the
previous contents of $LOCAL_FILE. So whichever version of the
$REMOTE_FILE we chance to keep around, it will be fine. If our version
is reasonably up to date, then the file transfer goes faster. If it is
very wrong, then the file transfer goes at normal speed.
This discussion makes me wonder: What is the use of the rsync method?
On the one hand, we guess that it is not useful, for most files being
edited are small. On the other hand, if people explicitly choose the
rsync method, then perhaps this is because they expect some benefit from
it. And it is clear that they can expect any benefit when editing small
files. So perhaps the rsync method user community is exactly that
subset of the Tramp users who regularly edit large files remotely?
*scratches head*
Kai
PS: I just assume, but haven't tested, that "rsync $REMOTE_FILE
$NEW_LOCAL_FILE" runs at about the same speed as "rsync $REMOTE_FILE
$RANDOM_LOCAL_FILE" for the same $REMOTE_FILE. ($NEW_LOCAL_FILE is a
file that does not exist, $RANDOM_LOCAL_FILE is an existing file with
contents that are very different from the contents of the $REMOTE_FILE.
Perhaps if $RANDOM_LOCAL_FILE is very large then this does not hold?)
_______________________________________________
Tramp-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/tramp-devel
