Strange sender log file characters

Is there a reason I get the following strange characters in my log file?

2008/08/29 19:48:13 [7138] Number of files: 42321
2008/08/29 19:48:13 [7138] Number of files transferred: 78
2008/08/29 19:48:13 [7138] Total file size: +)*)/.+),00//,+)),( bytes
2008/08/29 19:48:13 [7138] Total transferred file size: +)*)/.+),(*0,+-.,0'
bytes
2008/08/29 19:48:13 [7138] Literal data: -+,((0),' bytes
2008/08/29 19:48:13 [7138] Matched data: 9573940 bytes
2008/08/29 19:48:13 [7138] File list size: 1623316
2008/08/29 19:48:13 [7138] File list generation time: 17.259 seconds
2008/08/29 19:48:13 [7138] File list transfer time: 0.000 seconds
2008/08/29 19:48:13 [7138] Total bytes sent: 20093247
2008/08/29 19:48:13 [7138] Total bytes received: 71734
2008/08/29 19:48:13 [7138] sent 20093247 bytes received 71734 bytes
485903.16 bytes/sec
2008/08/29 19:48:13 [7138] total size is +)*)/.+),00//,+)),( speedup is
-285997082764.99

Thanks
Denys

--
View this message in context: [url]http://www.nabble.com/Strange-sender-log-file-characters-tp19231243p19231243.html[/url]
Sent from the Samba - rsync mailing list archive at Nabble.com.

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Sat, Aug 30, 2008 at 12:52:42AM -0700, dfirth wrote:[color=blue]
> Is there a reason I get the following strange characters in my log file?[/color]

What rsync version are you using? I've never seen that before. Also,
which of the various PRINTF defines are defined in your config.h file?

% fgrep PRINTF config.h
#define HAVE_ASPRINTF 1
#define HAVE_C99_VSNPRINTF 1
#define HAVE_SNPRINTF 1
#define HAVE_VASPRINTF 1
#define HAVE_VSNPRINTF 1

...wayne..
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Sat, 2008-08-30 at 00:52 -0700, dfirth wrote: [color=blue]
> Is there a reason I get the following strange characters in my log file?
>
> 2008/08/29 19:48:13 [7138] Total file size: +)*)/.+),00//,+)),( bytes
> 2008/08/29 19:48:13 [7138] Total transferred file size: +)*)/.+),(*0,+-.,0'
> bytes
> 2008/08/29 19:48:13 [7138] Literal data: -+,((0),' bytes
> 2008/08/29 19:48:13 [7138] total size is +)*)/.+),00//,+)),( speedup is
> -285997082764.99[/color]

That can happen if the statistics somehow become negative because the
"big_num" function doesn't handle negative numbers. The following patch
makes it handle them:

[url]http://mattmccutchen.net/rsync/rsync.git/?a=commitdiff;h=wip/negative-stats[/url]

We still have to figure out how the statistics become negative. You
could run rsync under gdb with "watch (stats.total_size < 0)", or if you
have a reproducible case, I would be happy to look into it.

Matt

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki55JQACgkQC+xSYN/Rlfs32gCeJLaYcjEworlcaHdGH+Y0zXff
QNAAnA0885h6ZXNVKY9gVoQdsc1dAaSU
=iSy+
-----END PGP SIGNATURE-----

I believe I have found the reason/cause.
The (source) disk in question had been part of a linux (fake) raid1 setup
that started having errors. The raid was undone, and this seemed to fix the
errors. However, I have now noticed that readings of disk usage were odd and
that some parts of the disk were reportedly unreadable. I ran a e2fsck and
it was riddled with errors, some unfixable.
I have mirrored the disk using rsync (with still some read errors reported).
The log files are now OK on the new disk using the same rsync script.
So I believe the cause was a badly corrupted disk. (If I had given you the
complete rsync log file you would have seen at the start the 8 or so
file/folders with either file vanished or input/output error(5) which would
have given a clue, I guess.)
Your quick response was much appreciated (what a great tool rsync is!)
Denys



Wayne Davison-2 wrote:[color=blue]
>
> On Sat, Aug 30, 2008 at 12:52:42AM -0700, dfirth wrote:[color=green]
>> Is there a reason I get the following strange characters in my log file?[/color]
>
> What rsync version are you using? I've never seen that before. Also,
> which of the various PRINTF defines are defined in your config.h file?
>
> % fgrep PRINTF config.h
> #define HAVE_ASPRINTF 1
> #define HAVE_C99_VSNPRINTF 1
> #define HAVE_SNPRINTF 1
> #define HAVE_VASPRINTF 1
> #define HAVE_VSNPRINTF 1
>
> ..wayne..
> --
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
> [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
> Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]
>
>[/color]

--
View this message in context: [url]http://www.nabble.com/Strange-sender-log-file-characters-tp19231243p19247901.html[/url]
Sent from the Samba - rsync mailing list archive at Nabble.com.

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Sat, 2008-08-30 at 20:24 -0400, Matt McCutchen wrote:[color=blue]
> That can happen if the statistics somehow become negative because the
> "big_num" function doesn't handle negative numbers. The following patch
> makes it handle them:
>
> [url]http://mattmccutchen.net/rsync/rsync.git/?a=commitdiff;h=wip/negative-stats[/url][/color]

Wayne, you might want to consider applying this even though the
immediate problem is solved.

Matt

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki7VuwACgkQC+xSYN/RlfuXRgCgr1pt9ZlL1c6e79jC6S7bD3u7
Fv8AnRz5E4Np1ckEvWMo5xaV+O/C0EDu
=Gq2S
-----END PGP SIGNATURE-----

On Sun, Aug 31, 2008 at 10:44:11PM -0400, Matt McCutchen wrote:[color=blue]
> Wayne, you might want to consider applying this even though the
> immediate problem is solved.[/color]

Yeah, I had noticed that lack-of-negative number-handling deficiency
when I was working on an enhancement for 3.1.0 to output numbers in
3-digit clusters (e.g. 1,234,567). I hadn't thought that I needed
special handling of INT_MIN, though, so I fixed that. I've gone ahead
and committed my enhancement to the 3.1.0 branch, and ported that
improved negation fix from the trunk to the 3.0.x branch.

I'm interesting in what folks think about my making the outputting of
clustered numbers the default for 3.1.0 (see the --human-readable option
in the 3.1.0 manpage for a full discussion of how it works and is
overridden). The code attempts to intuit if it should use a comma or a
period for the 3-digit clustering based on if sprintf() puts a period or
a comma into a floating point number.

...wayne..
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Mon, 2008-09-01 at 13:31 -0700, Wayne Davison wrote:[color=blue]
> On Sun, Aug 31, 2008 at 10:44:11PM -0400, Matt McCutchen wrote:[color=green]
> > Wayne, you might want to consider applying this even though the
> > immediate problem is solved.[/color]
>
> Yeah, I had noticed that lack-of-negative number-handling deficiency
> when I was working on an enhancement for 3.1.0 to output numbers in
> 3-digit clusters (e.g. 1,234,567). I hadn't thought that I needed
> special handling of INT_MIN, though, so I fixed that. I've gone ahead
> and committed my enhancement to the 3.1.0 branch, and ported that
> improved negation fix from the trunk to the 3.0.x branch.
>
> I'm interesting in what folks think about my making the outputting of
> clustered numbers the default for 3.1.0 (see the --human-readable option
> in the 3.1.0 manpage for a full discussion of how it works and is
> overridden). The code attempts to intuit if it should use a comma or a
> period for the 3-digit clustering based on if sprintf() puts a period or
> a comma into a floating point number.
>
> ..wayne..[/color]

Reading the snprintf manpage (at least on Linux). It seem you don't have
to meka eany special manipulation to get the thousands separator but
just use the "'" modifer:

The five flag characters above are defined in the C standard. The
SUSv2 specifies one further flag character.

’ For decimal conversion (i, d, u, f, F, g, G) the output is to be
grouped with thousands’ grouping characters if the locale infor-
mation indicates any. Note that many versions of gcc(1) cannot
parse this option and will issue a warning. SUSv2 does not
include %’F.


The advantage of using a glibc function is that it uses the correct
locale settings for the thousands separator and does not require
guessing.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Tue, Sep 02, 2008 at 09:11:22AM -0400, Simo Sorce wrote:[color=blue]
> The advantage of using a glibc function is that it uses the correct
> locale settings for the thousands separator and does not require
> guessing.[/color]

Rsync has to be able to run on systems that don't use glibc, so I
decided not to use that feature. Rsync doesn't even output 64-bit
numbers using printf() since the flag character for such a large
value is not standardized.

...wayne..
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Tue, 2008-09-02 at 16:05 -0700, Wayne Davison wrote:[color=blue]
> On Tue, Sep 02, 2008 at 09:11:22AM -0400, Simo Sorce wrote:[color=green]
> > The advantage of using a glibc function is that it uses the correct
> > locale settings for the thousands separator and does not require
> > guessing.[/color]
>
> Rsync has to be able to run on systems that don't use glibc, so I
> decided not to use that feature. Rsync doesn't even output 64-bit
> numbers using printf() since the flag character for such a large
> value is not standardized.[/color]

In samba we detect the features of the system [s[n]]printf() and replace
it with our own if it does not meet all requirements, maybe we can get
that code and use it in rsync too ?

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]