similar to: [Bug 10941] New: include should supersede max-size

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try it without any --delete options. On 03/27/2015 09:31 AM, Aron Rotteveel wrote: > I am now running with --delete --numeric-ids --relative but the > problem still persists. > > -- Best regards / Met vriendelijke groet, > > Aron Rotteveel > > 2015-03-27 14:22 GMT+01:00 Kevin Korb <kmk at sanitarium.net >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try also removing --delete-excluded. Without those two options there should be no reason for rsync to require gigs of RAM. Well, unless the other system has rsync 2.x. On 03/27/2015 07:29 AM, Aron Rotteveel wrote: > Yes, I removed "--no-inc-recursive", without success. > > -- Best regards / Met vriendelijke groet, > >

Hi, I am experiencing segfaults when transferring files via rsync though sudo. Setup: - Backupserver initiates the rsync command with --delete -vvv --no-inc-recursive --numeric-ids --delete-excluded --relative --rsync-path=/home/backupuser/rsync-wrapper.sh - rsync-wrapper.sh (on the client) contains /usr/bin/sudo /usr/bin/rsync "$@"; - user "backupuser" has sudo access to the

for pre 3.0.9 which is still standard in centos7 with recent updates, --stats does neither show number of deleted, nor added files Am 17. Dezember 2016 18:06:56 MEZ, schrieb Kevin Korb <kmk at sanitarium.net>: >--stats has most of that information in it. > >On 12/17/2016 08:01 AM, devzero at web.de wrote: >> is there a script which analyses rsync output with --itemize-changes

is there a script which analyses rsync output with --itemize-changes ? i.e. i would like to have extended information on number of deleted files, created directories, changed files.... i know rsync 3.1.x is better with this, but it`s still not in centos 5/6/7 and i don`t want to update tons of systems to get extended statistics, so i wonder if anbody did an analyze script to get that information

from a security perspective this is bad. think of a backup provider who wants to make rsyncd modules available to the end users so they can push backups to the server. do you think that such server is secure if all users are allowed to open up an ssh shell to secure their rsync transfer ? ok, you can restrict the ssh connection, but you open up a hole and you need to think twice to make it secure

Hi ! I`m getting "rsync warning: some files vanished before they could be transferred (code 24) at main.c(1518) [generator=3.0.9]" on one of my systems i`m backing up with rsync , but rsync doesn`t show WHICH files. Does anybody have a clue under which circumstances rsync doesn`t show these ? regards Roland

> The benefit of rsync over ssh secured by rrsync is that it is more > like what rsync users are already used to. i don`t like rsync over ssh in an environemt with users you can?t trust. from a security perspective, i think such setup is broken by design. it`s a little bit like giving a foreigner the key to your front door and then hope that the door in the corridor to your room will be

> There have been addons to rsync in the past to do that but rsync really > isn't the correct tool for the job. why not correct tool ? if rsync can greatly keep two large files in sync between source and destination (using --inplace), why should it (generally spoken) not also be used to keep two blockdevices in sync ? maybe these links are interesting in that context:

> You are missing the point of the checksum. It is a verification that > the file was assembled on the target system correctly. The only > post-transfer checksum that would make any sense locally would be to > make sure that the disk stored the file correctly which would require > a flushing of the cache and a re-reading of the file. Rsync has no > capability to do this

But don‘t forget —inplace, otherwise snapshots would not be efficient > Gesendet: Mittwoch, 18. Juli 2018 um 21:53 Uhr > Von: "Kevin Korb via rsync" <rsync at lists.samba.org> > An: rsync at lists.samba.org > Betreff: Re: link-dest and batch-file > > If you are using ZFS then forget --link-dest. Just rsync to the same > zfs mount every time and do a zfs

i'm using rsync for backup and, as rsync can detect if files have vanished during transfer, i wonder how rsync can tell which files got modified during transfer (i.e. which are not consistent on the destination side after transfer) apparently, rsync can't show that information? wouldn't that be an extremely useful feature if rsync could do another additional mtime or even checksum

An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20180323/66c46d5a/attachment.html>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You didn't say if you were networking or what features of rsync you are using but if you aren't networking and aren't doing anything fancy you are probably better off with cp -au which is essentially the same as rsync -au except faster. Anyways, smaller reads and writes are usually better handled by the OS's caches than really big

https://bugzilla.samba.org/show_bug.cgi?id=11423 Bug ID: 11423 Summary: rsync 3.1.x is creating empty backup directories Product: rsync Version: 3.1.1 Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: core Assignee: wayned at samba.org

On Tue, Mar 20, 2018 at 5:49 PM Kevin Korb <kmk at sanitarium.net> wrote: > Nothing there should be preventing incremental indexing. That means it > should start copying as soon as it finds a file that needs to be copied. > Doesn't it tries to create all (empty) directories first? > On 03/20/2018 02:33 PM, Bráulio Bhavamitra wrote: > > > > > > Em seg, 19

OK. Thanks. Where can I find information regarding how to interpret —itemize-changes? The timestamps aren’t changing, so the target must not be storing them, which I have no idea why. The directory I’m writing to is 777. What is the flag to tell rsync to ignore the timestamps? Thanks, Blake On 6/2/16, 6:18 PM, "rsync on behalf of Kevin Korb" <rsync-bounces at lists.samba.org on

Rsync has no memory of what other instances of rsync have done in the past. An existing file with a different name is of no interest to it unless --delete in which case it would be deleted. Maybe what you really want is --partial-dir? On 6/7/23 16:17, Lacey, Nathan wrote: > I'm suggesting a partial file that isn't hidden is worse. > Because any other app looking at the file

Em seg, 19 de mar de 2018 11:34, Kevin Korb via rsync <rsync at lists.samba.org> escreveu: > The performance of rsync with a huge number of files is greatly > determined by every option you are using. So, what is your whole > command line? > rsync -avP /data-old/ /data > > On 03/19/2018 09:05 AM, Bráulio Bhavamitra via rsync wrote: > > Hi all, > > > >

https://bugzilla.samba.org/show_bug.cgi?id=10405 Summary: Feature request: Add support for pre/post cmds for the rsync client Product: rsync Version: 3.1.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org