On Tue, Mar 07, 2023 at 01:16:07PM +0100, Heiko Schlittermann via rsync wrote:
> Robin Lee Powell via rsync (Di 07 Mär 2023 07:07:01
> CET):
> > Read the "PER-DIRECTORY RULES AND DELETE" of the man page. (And
> > don't feel bad, it took me a while to figur
Read the "PER-DIRECTORY RULES AND DELETE" of the man page. (And
don't feel bad, it took me a while to figure it out myself).
Short version: per-directory rules only apply on the side they're
*specified on*, but you need the exclusion to apply to *both* sides.
The following works, for the reasons
Oh, yeah, I missed that part. Yeah, don't do that; it's easy to add
a lock file to a shell script.
On Sun, Mar 05, 2023 at 12:30:16PM +0100, Hardy via rsync wrote:
> I second Francis here. You don't need to diagnose incomplete file transfers
> as long as you have racing conditions as you describ
I think it's very hard to be sure what's going on with
--remove-source-files ; I think you should drop that option, look
for whether the problem continues, and if you need the files to be
cleaned up, do so in a separate step.
In particular as someone else suggested, are you *sure* the original
cop
That's not the same as a read-back write verification.
I believe that in general, rsync assumes that the disk actually
wrote whatever it was told to write.
However, a second pass with --checksum will, in fact, read the
entirety of both files; if a --checksum run doesn't actually
transfer anything
Yeah, I was thinking tar, but it's effectively the same thing.
On Sat, Feb 11, 2023 at 07:14:57PM +0100, Hardy via rsync wrote:
> If this helps, in old days I used to use cpio for a similar thing.
>
> I do not want to spam you with my whole script, but willing to share if you
> want. I think you
No.
On Sun, Aug 07, 2022 at 06:49:45AM +0200, Fourhundred Thecat via rsync wrote:
> Hello,
>
> is there any difference/advantage between these two commands?
>
> rsync --rsh="ssh -l root" my-host.com
> rsync r...@my-host.com
>
> thank you,
>
> --
> Please use reply
I've definitely not seen that. If you can produce a working example
and tar it up for us to look at, that might be interesting/useful.
Just to check, though: you do not have --checksum/-c on, right?
On Sat, Aug 06, 2022 at 05:54:12PM +, Gregory Heytings via rsync wrote:
>
> I finally take t
On Wed, Aug 03, 2022 at 02:04:22PM -0400, Rob Campbell via rsync wrote:
> I've created a script that syncs (and removes) data from as many as 4
> places and puts them all in one of 2 directories. The commands are:
>
> rsync -avt --progress --remove-source-files --info=progress2 -f'+ *.nef'
> -
...
That's ...
Behaviour confirmed. That is *not* cool.
On Fri, Jul 15, 2022 at 04:18:18AM -0400, Kevin Korb wrote:
> Yeah, unfortunately rsync's --checksum doesn't even employ obvious
> optimizations that the man page says it does. There is no reason for it to
> checksum files that only exist
--checksum is only slower than re-copying if your network connection
between the hosts is similar in speed (or faster than) each host's
local disk access.
If local disk access is 10x your network link, it is definitely not
slower than re-copying.
Having said that, it really is *very* slow, and be
So I'm not quite following your Windows rsync problem.
Specifically, do you mean:
"I copied files A, B, and C, and there's still 3 files but each file
is bigger"
or
"I copied files A, B, and C to a directory containing files that I
thought were identical using the -b flag but now there's twice a
It would help if you gave us an example of what you'd *want* to have
happen in different situations, but what about the -b option? This
will do nothing with identical files but keep both versions of
non-identical ones.
On Wed, Jun 08, 2022 at 12:24:16AM +, hput via rsync wrote:
> I want to me
On Sun, Aug 15, 2021 at 07:03:18AM +0200, Fourhundred Thecat via rsync wrote:
> Hello,
>
> is there a way to suppress this message when syncing files?
>
>is uptodate
>
> I would like to see only files that have been synced.
>
> The internet forums are full of people asking how to get rid
14 matches
Mail list logo