Displaying 20 results from an estimated 4000 matches similar to: "--link-dest --inplace updates files without unlinking. What to do?"
2014 Dec 26
2
Re[2]: --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
2014 Dec 27
2
Re[2]: --link-dest --inplace updates files without unlinking. What to do?
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
2014 Dec 26
2
Re[2]: --link-dest --inplace updates files without unlinking. What to do?
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
2014 Dec 27
2
Re[2]: --link-dest --inplace updates files without unlinking. What to do?
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
2014 Dec 27
2
Re[2]: --link-dest --inplace updates files without unlinking. What to do?
This is OK for me. I care about file contents, not metadata.
==
Askar Safin
http://vk.com/safinaskar
Kazan, Russia
2014 Dec 27
2
Re[2]: --link-dest --inplace updates files without unlinking. What to do?
>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
2014 Dec 27
1
Re[2]: --link-dest --inplace updates files without unlinking. What to do?
>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
2014 Dec 26
0
--link-dest --inplace updates files without unlinking. What to do?
-----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
2014 Dec 26
0
--link-dest --inplace updates files without unlinking. What to do?
-----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
2014 Dec 27
0
--link-dest --inplace updates files without unlinking. What to do?
-----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,
2014 Dec 27
0
--link-dest --inplace updates files without unlinking. What to do?
-----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
2014 Dec 27
0
--link-dest --inplace updates files without unlinking. What to do?
-----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
2008 Jan 14
7
DO NOT REPLY [Bug 5201] New: Rsync lets user corrupt dest by applying non-inplace batch in inplace mode
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:
2006 Sep 04
7
DO NOT REPLY [Bug 4079] New: rsync fails with --inplace, --link-dest and --no-whole-file
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
2007 Oct 28
2
DO NOT REPLY [Bug 5051] New: --copy-dest copies should use a temporary file unless --inplace
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
2007 Dec 14
0
Rsync lets user corrupt dest by applying non-inplace batch in inplace mode
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
2019 Jun 26
2
Allow "--in-place" as an alternative option name for "--inplace"
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
---
2015 Apr 14
1
The --inplace is very different from the behaviour of --partial when resuming a complex case transfer.
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/
2015 Dec 26
1
[Bug 11651] New: Can we allow --inplace and --sparse to coexist when --whole-file is in play?
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
2007 Jul 30
2
DO NOT REPLY [Bug 4834] New: --inplace with --backup --backup-dir does not work
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