similar to: --link-dest --inplace updates files without unlinking. What to do?

>- --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 incomplete or corrupt copies on

No. Now there is no --inplace. So, rsync will never write new file directly into old one (without unlinking). If there already is old file and it needs updating, then rsync will write into something like .file-He4gw, and then it will rename this file to its right name. This new file will not have any hardlinks to old files == Askar Safin http://vk.com/safinaskar Kazan, Russia

Ok, thanks. I removed --inplace and --append-verify and kept --link-dest and --partial. And now the script works exactly as I want: hard-links are not updated, the script is still robust and can copy large files over unstable links etc, etc. == Askar Safin http://vk.com/safinaskar Kazan, Russia

I don't specify --partial-dir. As you can see from the script, rsync at first copies to "in-progress", and then renames this to (for example) 2014-12-01-000000. So, if rsync interrupts, then at the next run the script will end "in-progress" (all partial files will be done) and then will rename this dir to 2014-12-01-000000. So, there never will be partial files in finished

This is OK for me. I care about file contents, not metadata. == Askar Safin http://vk.com/safinaskar Kazan, Russia

>BTW, if you want it to always have that behavior (it can save a lot of >backup space) you can use the old cp -al method instead of --link-dest >so that the target dir starts out completely populated. You mean making "cp -al" on the remote and then start rsync to newly created dir with --partial and without --link-dest, --inplace, --append-verify? What is benefits? Even metadata

>I mean instead of having --link-dest=previous_backup and the target >being empty (or starting that way in your case) you cp -al the >prevous_backup to the new "incomplete" one. Now you have a tree full >of all hard links. Now you can rsync to the target without any >- --link-dest reference. I meant the same. >You are right about the other options except >that you

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, but there are issues to keep in mind... Normally --link-dest is used to keep previous copies (to make a backup system) and the target directory is always empty. In this mode - --inplace and --append-verify would be irrelevant since rsync will always be either making a link or writing an entire new file. However, if you have an unstable link

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am talking about metadata. Permissions, ownerships, etc. If a link exists in the target and needs a metadata change then rsync will do a chmod, chown, whatever which updates all the instances of the file. If there hadn't already been a link there rsync would have written out an entire new file to have the new metadata. On 12/26/2014 08:32 PM,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are you specifying --partial-dir? Seems like that would be needed or else you will end up would end up with an incomplete copy in the previous target? On 12/26/2014 06:50 PM, Askar Safin wrote: > Ok, thanks. I removed --inplace and --append-verify and kept > --link-dest and --partial. And now the script works exactly as I > want: hard-links

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I mean instead of having --link-dest=previous_backup and the target being empty (or starting that way in your case) you cp -al the prevous_backup to the new "incomplete" one. Now you have a tree full of all hard links. Now you can rsync to the target without any - --link-dest reference. You are right about the other options except that

https://bugzilla.samba.org/show_bug.cgi?id=5201 Summary: Rsync lets user corrupt dest by applying non-inplace batch in inplace mode Product: rsync Version: 3.0.0 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

https://bugzilla.samba.org/show_bug.cgi?id=4079 Summary: rsync fails with --inplace, --link-dest and --no-whole- file Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org

https://bugzilla.samba.org/show_bug.cgi?id=5051 Summary: --copy-dest copies should use a temporary file unless -- inplace Product: rsync Version: 3.0.0 Platform: x86 OS/Version: Linux Status: NEW Severity: minor Priority: P3 Component: core AssignedTo: wayned@samba.org

Wayne, I noticed that rsync will let me apply a non-inplace batch file in inplace mode. This corrupts the destination file if the batch file copies any data forward (from earlier offsets to later ones). Of course, the post-transfer checksum detects the corruption and gives the "ERROR: <file> failed verification" message, but rsync doesn't give the user a clue why the

Hi! As I commonly spell --inplace as --in-place, I'd like to suggest this simple patch: commit 5689f99b702788044a45e13582559832cf986328 Author: Jan-Benedict Glaw <jbglaw at lug-owl.de> Date: Wed Jun 26 22:49:31 2019 +0200 Allow "--in-place" as an alternative option name for "--inplace". diff --git a/options.c b/options.c index e5b0cb68..7ff0c51d 100644 ---

Hi all, >From the manpage of rsync, I can see the following descriptions: --inplace The option implies --partial (since an interrupted transfer does not delete the file) So I do the following testings on the `--inplace' and `--partial' for resuming a file with the following steps: 1- rsync ftp.cn.debian.org::debian/dists/wheezy/main/binary-amd64/

https://bugzilla.samba.org/show_bug.cgi?id=11651 Bug ID: 11651 Summary: Can we allow --inplace and --sparse to coexist when --whole-file is in play? Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: core

https://bugzilla.samba.org/show_bug.cgi?id=4834 Summary: --inplace with --backup --backup-dir does not work Product: rsync Version: 2.6.9 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: joost@seat-ibiza.nl