similar to: Feature I'd love to see: --move-dest

(I'm not sending this to dirvish@pegasus because I think that this message applies more to rsync's --link-dest option than to just dirvish.) I recently noticed a huge spike in dirvish network usage and traced it to files whose permissions had been changed. (with rsync v2.5.6) I understand and agree that a --link-dest copy of a source file cannot be hardlinked to, but couldn't a

Hi, I can't manage to get rsync's --link-dest option working. Here is a step by step script which doesn't produce the good results. # create test dir mkdir testrsync cd testrsync mkdir orig echo "abcd" > orig/testfile # create a mirror rsync -apog orig/ mirror/ # create another mirror using link-dest rsync -apog --link-dest=mirror/ orig/ mirror2/ # look at inodes ls

I use rsync to backup my system, using a command-line such as the following: > rsync [src] [dst] -a --link-dest --size-only In this case, [src] is produced by a command that makes no attempt to preserve timestamps ("svnadmin hotcopy", in this case). That's why I use --size-only. Here's the rub: identical files aren't hard-linked like I expect them to be. They're full

This has been a consideration. But it pains me that a tiny change/addition to the rsync option set would save much time and space for other legit use cases. We know rsync very well, we dont know ZFS very well (licensing kept the tech out of our linux-centric operations). We've been using it but we're not experts yet. Thanks for the suggestion. /kc On Mon, Apr 06, 2015 at 12:07:05PM

Feature request: allow --link-dest dir to be linked to even if file exists in target. This statement from the man page is adhered to too strongly IMHO: "This option works best when copying into an empty destination hierarchy, as rsync treats existing files as definitive (so it never looks in the link-dest dirs when a destination file already exists)". I was suprised by this behaviour

I've got a problem for which the combination of -R and --link-dest doesn't seem to be quite enough---and I may have discovered a few small bugs as well; test cases are below. [And if someone has a scheme for doing this that doesn't involve rsync at all, but works okay, I'm all ears as well---I'm not the first with this problem.] Here's my problem: I unfortunately need to

https://bugzilla.samba.org/show_bug.cgi?id=3692 Summary: regression: symlinks are created as hardlinks with -- link-dest Product: rsync Version: 2.6.7 Platform: x86 URL: http://rsync.samba.org OS/Version: FreeBSD Status: NEW Severity: major Priority: P3 Component: core

Hi all, I have just migrated my tooling from version 2.6.9 to 3.0.0. Unfortunately my script generated an error message during the execution. Because this command was working perfectly in the previous version I suspect this could be a bug. This is the command that I am executing: rsync -av --link-dest=20080313/ --compare-dest=/data/20080313/ 20080313/ /data/20080314/ It just

https://bugzilla.samba.org/show_bug.cgi?id=3693 Summary: rsync can use same --link-dest file several times, leading to incorrect hard links Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

https://bugzilla.samba.org/show_bug.cgi?id=2947 wayned@samba.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From wayned@samba.org 2005-08-03 16:45 ------- Keep in mind that --link-dest only hard-links regular

On Mon, Jun 02, 2003 at 03:32:04PM -0700, Michael Rubel wrote: > Hi J.W., > > Please pardon this intrusion on your private address; the rsync list seems > to be down (no messages since yesterday), so I'm forwarding this directly > to you. If you'd rather wait until the list restarts, that's fine too. I'm CCing the list. > > Best regards, > Mike >

Hello, I'm trying to do backups with rsync through ssh. This is what I wrote yet: src="/vrmd/webserver/" today=`date +%F` #link_dest="root@vm2:/vrmd/admin/backup/web/2004-09-05" link_dest="../2004-09-05" dest="root@vm2:/vrmd/admin/backup/web/$today" rsync -av -e ssh --delete --link-dest=$link_dest $src $dest in 2004-09-05 (on the dest-server) is the

Hi Kevin, Thanks for your quick response. The rsyncd.conf file looks like: charset = utf-8 [user] path = /c/user comment = "" use chroot = true uid = root gid = root read only = false auth users = admin I'm still confused about how to specify the path. The actual UNIX path is: /c/user/snapshots/rsync_test/last I've tried: --link-dest=snapshots/rsync_test/last

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

rsyncd doesn't take unix paths. You must adapt your --link-dest to contend with however the rsycd module is defined in rsyncd.conf. On 1/11/25 9:52 PM, Anthony LaTorre via rsync wrote: > Hi all, > > I'm trying to figure out why a script works when using SSH but not > when using the rsync protocol. When I run the following command: > > rsync -aPh

Hi all, I'm trying to figure out why a script works when using SSH but not when using the rsync protocol. When I run the following command: rsync -aPh --link-dest=/user/snapshots/rsync_test/last /home/user/rsync_test root at readynas.internal:/user/snapshots/rsync_test/Jan_11_2025 it works perfectly, correctly recognizing the link-dest parameter. However, when I try to run the same command

Using: # rsync --version rsync version 3.0.7 protocol version 30 Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes rsync comes with ABSOLUTELY NO

I must be seriously misunderstanding the man page coverage of --compre-dest. My take was that if a file in compare-dest=dir matches a file in SOURCE/ then it won't be transferred to DEST/. I tried this test. (d1 has single files and 2 subdir with files) cp -a d1 d1a mkdir d2 rsync -avv --compare-dest="./d1a" d1/ d2/ d1a is carbon copy of d1 but still every last file in

Hi, I've been attempting to use --compare-dest DIR SOURCE/ DEST/ If a file exists in DEST but is different to the corresponding file in DIR, then the file is updated in DEST. This is what I would expect. I have found that files which do not exist in DEST but do exist in DIR and SOURCE, are not created. Simply touching the file in DEST causes it to be updated. This behaviour seems

Hi all. A while ago (April 15th or so) I posted a patch that allows rsync to take multiple --compare-dest or --link-dest arguments, allowing fetching of files not present in multiple trees. I never got any feedback on it, though, so I'm picking it up again. :) Is there any interest in such a patch at all? Below is the usage example i outlined back then; --start-- [...] Its primary usage is