> the original message.
>
>
> From: rsync [rsync-boun...@lists.samba.org] on behalf of Kevin Korb via rsync
> [rsync@lists.samba.org]
> Sent: Thursday, March 23, 2017 1:10 PM
> To: rsync@lists.samba.org
> Subject: Re: rsync: "-c
org
Subject: Re: rsync: "-c" option clarification
Before anyone yells at me, yes, you can use rsync's --checksum to detect
(and fix) files that are incorrect despite having correct timestamps and
sizes. This would mean that a previous rsync had been corrupted not the
current one. Bu
via rsync wrote:
> The -c option causes rsync to checksum EVERY file on both ends BEFORE
> rsync does anything else. It checksums files that are on only 1 end.
> It checksums files that are different sizes. It will not catch a
> hardware problem preventing rsync from writing a file correct
The -c option causes rsync to checksum EVERY file on both ends BEFORE
rsync does anything else. It checksums files that are on only 1 end.
It checksums files that are different sizes. It will not catch a
hardware problem preventing rsync from writing a file correctly.
On 03/23/2017 03:12 PM
Hi
I am using "rsync" to send files from a source machine to a remote machine as
one typically does. I would like to clarify that the "-c" option will cause
the checksum on the receiving end to be created by reading the already written
file and NOT the data stream
On Sat, Mar 21, 2009 at 02:06:42PM +0100, Christian Hecht wrote:
> Now my question is, when i use rsync with the -c option, is it possible to
> output the filename and the generated hash to any file?
Rsync 3.1.0dev supports the %C escape in log formats, which can output
the sender'
and want to compare it with the hash which was
stored in the previous run.
Now my question is, when i use rsync with the -c option, is it
possible to output the filename and the generated hash to any file?
Best regards
Christian
--
Please use reply-all for most replies to avoid omitting the
he data in a file might change without changing the mtime, ctime or
> | size? I'm not sure I've ever come across that before. An example might
> | help me determine if I can safely remove -c.
>
> I ran into a situation where I had to use the -c option. I use two
> rsync c
m not sure I've ever come across that before. An example might
| help me determine if I can safely remove -c.
I ran into a situation where I had to use the -c option. I use two
rsync commands to install Linux onto new PCs, the first one to "clone"
a system, and a second one to u
> Quick questioncan anyone explain to me when the data in a file
> might change without changing the mtime, ctime or size? I'm not
> sure I've ever come across that before. An example might help me
> determine if I can safely remove -c.
It's possible on Unix systems, but not practical.
An
Actually,
We have the problem here. We have an NFS server mounted on a mix
of Solaris, AIX, HP, True64, NT and VMS. What seems to be happening is
that something on the VMS side updates the file which creates a new
version. On the unix side the plain files is somehow linked to the
> The only reason to use -c is if you have data which may be changed without
> changing mtime, ctime or size (is there any case where that happens?). It
That's great news. I believe this applies to me just fine and I
can turn off the checksum. Quick questioncan anyone explain to
ck(,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me Tim?"
Michael Montero <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/30/2002 08:27 AM
To: [EMAIL PROTECTED]
cc: (bcc: Tim Conway/LMT
Hello all. I've been using rsync for quite some time and when I
originally began using it I was religious about including the -c option.
I've read the man page and noticed the significant performance hit I take
in using it. I was wondering if someone would be able to clarify for m
14 matches
Mail list logo
