similar to: [Bug 10334] New: rsync doesn't log hardlink-copies using --link-dest

[please Cc: 666024-forwarded at bugs.debian.org on any replies, thanks] Please see the attached Debian bug report, which includes a helpful bug-reproducing shell script; I've confirmed this still happens with 3.0.9. Paul Slootman On Tue 27 Mar 2012, Ian Jackson wrote: > Package: rsync > Version: 3.0.7-2 > > With rsync --link-dest, if two different source files (not hardlinked

https://bugzilla.samba.org/show_bug.cgi?id=4793 Summary: link-dest hardlink does not always work well with -o -g -p Product: rsync Version: 2.6.9 Platform: PPC OS/Version: Linux Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned@samba.org

The rsync 2.5.6 TODO file mentions the need for hard link test cases. Here is one in which a linked file is unnecessarily transferred in full. # Setup initial directories mkdir src dest dd if=/dev/zero bs=1024 count=10000 of=src/a 2>/dev/null rsync -a src/. dest/. ln src/a src/b # At this point, a & b exist in src; only a exists in dest. rsync -aHv src/. dest/.

Hi! It's me again with another --link-dest issue: I am using dirvish (www.dirvish.org) to create daily backup on disk images. dirvish is using rsync with --link-dest pointing to the last good image. This creates images with hardlinks to unmodified files. So far so good. Now I want to create a "current" filetree with hardlinks pointing to the last image. rsync -vaH --delete

https://bugzilla.samba.org/show_bug.cgi?id=9749 Summary: hardlinkes files are copies instat of make a link Product: rsync Version: 3.0.9 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: dieter.ferdinand at

rsync 2.6.9 --link-dest does - not hardlink special files (symlink, device nodes) This doesn't take much space, but it clutters the logfiles - change owner/groupship on the hardlink So if I use a hard-linked-tree-per-day, it changes history also Is this still the same with newer versions? Are there options to modify this behavior? If not, why not? :-) louis -- GMX FreeMail: 1 GB

https://bugzilla.samba.org/show_bug.cgi?id=13656 Bug ID: 13656 Summary: --link-dest target with symbolic links from different user produces unnecessary error Product: rsync Version: 3.1.3 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 Component:

I notice that devices are not hardlinked when using the --link-dest option, for instance: rsync -aH --link-dest=../bar/ foo/ baz/ When foo/zero is a device, baz/zero is not a hardlink to bar/zero. How come? $ rsync --version rsync version 2.5.6 protocol version 26 on linux 2.4.x -- Russell Senior ``I have nine fingers; you have ten.'' seniorr@aracnet.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --inplace and --append-verify are essentially irrelevant when - --link-dest is in play. With --link-dest in play the target system must write an entirely new file even for a change in permissions or timestamps so any potential benefit by these options are out the window from the start. The only thing they can do is add the possibility of

https://bugzilla.samba.org/show_bug.cgi?id=10352 Summary: link-by-hash hardlink-collection maintenance mode Product: rsync Version: 3.1.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: jimklimov at

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

Greetings All, I've been thinking about the current behavior of the --link-dest=DIR option. In the absence of --delete, ALL members of DIR should be linked to the destination (aside from those that are changed). If not, there should at least be a --no-link-dest-delete option. (This latter option might be better to avoid disrupting the behavior of current rsync commands) My rational: This

I use rsync to backup several servers to harddisk on a backupserver. To save space i use the --link-dest option which creates a hardlink to the file of the last backup if the file hasn?t changed. Under certain circumstances the file doesn?t exist in the last backup, but in the second last backup ore somwhere else. If for example a backup couldn?t be completed (maybe because of a loss of power)

Hi, I detected a silly behaviour of rsync when new hardlinks of already synced files are created: Scenario: There are a local directory and a equal remote directory created by former run of rsync. Create a hardlink from a already existing file (both inside the local directory). If this hardlink has a filename with comes before the original filename when both are sorted in alphabetic order,

I use rsync to backup several servers to harddisk on a backupserver. To save space i use the --link-dest option which creates a hardlink to the file of the last backup if the file hasn?t changed. If a file already exists in the destination directory then an maybe existing file in the --link-dest directory is ignored. The existing file will be overwritten with the new version regardless whether

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since you are in an environment with millions of files I highly recommend that you move to ZFS storage and use ZFS's subvolume snapshots instead of --link-dest. It is much more space efficient, rsync run time efficient, and the old backups can be deleted in seconds. Rsync doesn't have to understand anything about ZFS. You just rsync to the

Hi. This is bug report and simultaneously urgent asking for help. I am trying to write my rsync wrapper script, which will create minutely snapshots of my data using --link-dest. I want this script to be robust, it should work even if I do suspend/hibernate/reboot without notifying the script about this actions, it should work if I make hard-reset of the computer and if I disconnect network. Also

Hi list, I have a little script that uses rysnc and hardlink to perform backups. Some days ago a friend told me that rsync could crash if the hardlink limit is reached. I know (and tested) that for ext4 the max number of hardlink for a single file is 65000 but I can't get a limit on XFS. Due to the fact that I can't get good resources from google search, I tried to reach its limit

I'm running a mirror of several repositories that are fetched using separate rsync runs. Since some of those repositories are hosting related files, I'm using the hardlink utility[1] in order to save disk space. However, I've noticed an issue that may lead to potential file metadata inconsistencies when using hardlink. Consider the following scenario: - two repositories (rep_a and

Folks, We faced a similar situation to that which Ken described - we recycle backup directories, for good reason. There is a patch to solve the problem. Our systems administrator provided the following description of the patches we use: ============================================================================ 1. rsync_link_dest improvement by Bryant Hansen Normally, existing files in