similar to: issues syncing between one host and another

I have a string, "2012_10_16"; let's call this $YESTERDAY How can I rsync a file tree from a remote machine to the local one, including *only* filenames that contain the matching string? I've read the man page and googled around but can't seem to get the syntax right. I either end up syncing all the files, or none of them. Here's how the code looks now (I will remove

I am in the process of writing a script on some testing machines and I am wondering if having it perform a dry run and itemized the items if it would provide a list of differences such as file size and name etc conflicts -- Jonathan Aquilina -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I found that current rsync versions do something different when using --one-file-system --relative and --delete. This has all worked as expected with the old version (in our case those delivered with RHEL4 and 5) but it doesn't work correct in the 3.0.x version. I have opened a bug at RedHat because it's at least a regression for their upgrade from EL5.6 to EL5.7 which updated to

Hello, I'm using rsync as part of a centralised config management for several servers. I'm trying to monitor the mtime of a particular directory and confirm that the remote copies are approximately as new as the the local master. However, mtime on that directory is not being synced. Here's my rsync command: cd $confdir && rsync -avpzR --checksum -I -e "ssh"

Hello, I am trying to use the "--files-from=FILE" option with rsync version "version 2.6.3 protocol version 28" When I try to use the following syntax, it returns a syntax or usage error: rsync -azrv --files-from=/home/dira/filelist.txt remoteuser@remotehost:/remotedir I am also trying to use ssh with this which obviously yields an error also since the

Hi, When running an rsync command of the form: $ rsync -avn --delete remotehost:/mnt/volsw_dev/AS5/ /mnt/volsw_dev/AS5 rsync wants to delete a slew of files and directories. Partial output includes, for example: deleting AS5/zeromq/2.2.0/share/man/man7/zmq_tcp.7 deleting AS5/zeromq/2.2.0/share/man/man7/zmq_pgm.7 deleting AS5/zeromq/2.2.0/share/man/man7/zmq_ipc.7 deleting

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, thank you for this extra info. I have experienced exactly what you described. The rsync dry run is _still_ running after being started at 1:30am PST :) But it is finding the right files to update. Most of the entries are: >fc........ Which is what I want. So, just because I see: >f at the beginning... That doesn't necessarily mean that the file is going to get updated at the

-----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 >

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

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, > > > >

Thanks Kevin! I¹m unclear how to read the ‹itemize-changes output. Can you provide some insight? This is a local transfer from an external drive to an internal drive all attached to one computer. rsync -aPh --itemize-changes -n /Volumes/shuttle_05/2012_79_1_14_1__1199_Workprint /Volumes/3TB_LTO/LT003A/ sending incremental file list >f..t.......

On Sat Jan 10 2015 at 5:21:33 AM Kevin Korb <kmk at sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > What does --itemize-changes say about that file? Try using the stat > command on the various copies of it to see what is different about them. > In my original message, I stated I used --itemize-changes, and I reported the following: >

-----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, > >

Cool Thanks! Specifically, the timestamps on both <src> and <dest> match for "ls -l" but do not match for "ls -lu" or "ls -lc” The storage is just an regular HDD in a mac pro tower. I can’t imagine why it wouldn’t handle timestamps. Also of note - this problem doesn’t exist for every file, just the vast majority. So, that just makes it more confusing. Yes,

Thanks for the reply. The link-dest is different. It is Feb 1 while the source is Feb 2. I tried setting path = /media/external/ for the daemon and using rsync -a -v -i --delete --link-dest=backup-2016-02-01-0100 --password-file=/media/external/scripts/offsite_rsync.pass /media/external/backup/backup-2016-02-02-0100 backup at 192.168.2.102: :offsite/backup So all three (link-dest, source,

With the following server config: log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock [offsite] path = /media/external/ comment = Offsite backup read only = no hosts allow = 192.168.2.0/24 auth users = backup secrets file = /etc/rsyncd.scrt uid = 0 gid = 0 I tried the following for --link-dest and they all tried to transfer all

On Mon, Jan 26, 2015 at 05:04:10PM +0100, Pino Toscano wrote: > Currently implemented as guestfish commands, provide them instead as > single source -> destination functions for the library, so they can be > used also in other places. > > These functions are not added to guestfish, since guestfish has its own > implementation (which will soon switch to call copy-in and

What about -c? It seems I'm getting a lot of spurious file transfer candidates when using: -avvznIi --no-o --no-g --no-p It's showing transfers (receive) for many files I know haven't been tampered with. Thanks, -Clint On Tue, Oct 27, 2015 at 7:53 PM, Kevin Korb <kmk at sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > That is correct.

Thank you! I run --times when I use rsync (I actually use the -a flag) but the times do not transfer over and if I run rsync dryrun with -i I can see that it wants to transfer the files because of times. When I run rsync a second time with your suggestion the times do transfer over. I don't know why... B ________________________________________ From: rsync [rsync-bounces at lists.samba.org]