emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dired C idea


From: Fabrice Bauzac-Stehly
Subject: Re: Dired C idea
Date: Tue, 03 Aug 2021 23:30:54 +0200

Michael Albinus <michael.albinus@gmx.de> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>>>   > Should be feasible. The hard part is a rule to determine, whether rsync
>>>   > is better suited than the existing implementation, with the given actual
>>>   > arguments. I suspect, that small directories and/or short files are
>>>   > better served with the current implementation.
>>>
>>> Do we really need to decide this?  Wouldn't it be ok to use rsync
>>> for all cases (where Tramp is not in use)?
>>
>> I would like to see some benchmark figures first. For example, I'm not
>> sure that rsync performs better when the target directory does not exist
>> yet, and there's nothing to sync.
>
> I made some comparison between "cp -pr" and "rsync -pr" on shell
> level. I've copied the whole Emacs tree to somewhere else. First the
> case, that the target does not exist:

Beware, "cp -pr" preserves timestamps, while "rsync -pr" does not.
You'd have to add "-t" to rsync, which should make it much quicker when
the files are already there, because then rsync will trust stat(2)'s
mtime and size, skipping the actual opening and scanning of the files'
contents.  But if we don't trust this heuristics we would add
--ignore-times.  Also if we want to skip the rsync checksum scanning, and
mimic "cp" more, we can add --whole-file.  But it depends on what we
want to do?

The original use case of rsync is, of course, to synchronize things; in
particular, it will not prompt the user before overwriting a file, which
could be dangerous.  It can silently avoid overwrites with
--ignore-existing, though.  For this reason, I'm not sure it would be
wise to place it on the C key as replacement to the copy?

Another area where rsync shines is the possibility to fine-tune the
copying: --delete, rich filters on the sender and/or the receiver sides,
--copy-dest...  But then, precise control over the options is required,
so why not achieve that with the "!" key in Dired?

  ! rsync -rt "--filter=-s *.dat" --delete * /tmp/ RET

If we want to bind rsync to a Dired key, I guess its use would be to
give quick access to one (or two, with the prefix key...)  sets of rsync
options corresponding to the most common needs.  We can discuss what
they could be, for me it would probably look like this:

* (1) -a --hard-links -z --one-file-system --partial --exclude=.git/
  --exclude="*~"

* Same as (1), with --delete added

-- 
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6



reply via email to

[Prev in Thread] Current Thread [Next in Thread]