similar to: Progress reporting: N more to check

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/rsync/attachments/20040227/923b87ee/PGP.bin

In incremental recursion mode, the number of files "to check" can increase (when new file-list chunks are built) as well as decrease, which I found confusing to watch. This patch makes the progress line show the number of files "done" (which increases monotonically) instead. I did notice that the last progress line shows "done=N-1/N" instead of "done=N/N";

I've been looking at the --progress reporting, which is somewhat improved these days. But look at this output of this evening rawhide mirror update: [...] perl-DB_File-1.75-27.i386.rpm 73430 100% 519.63kB/s 0:00:00 perl-DB_File-1.75-28.99.3.i386.rpm 61783 100% 533.94kB/s 0:00:00 [...] Now, while it's good to have the ETA ticking down as something is fetched,

[ see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415648 ] When a source file grows during transfer, rsync may show negative time values such as 0:-1:-34. The following patch replaces then negative times with ??:??:?? in such cases (as IMHO it's not worth the bother of getting the filesize again etc. in such cases, but showing garbage info is wrong as well). Paul Slootman Index:

Hello, I have written a little script that's would email me all errors. rsync -vah --delete --stats <sources> <destination> > /var/log/sauvegarde/listoffile.log 2> /var/log/sauvegarde/errors.log My problem is i want to have the stats in my mail. Is it possible to redirect --stats to STDERR. I have tryed to do this : /---

Hi, I've read through the rsync manpage, this mailing list, asked Google and studied lots of posts on stackexchange.com (stackoverflow, superuser...), askubuntu.com and some others, concerning rsync's capabilities of showing progress information. But all I've found was what I already knew: --progress (or -P) shows a progress information for *every* file transmitted, --info=progress2

The attached diff causes rsync to show how much time it spends on building and sending its filelist. I'd appreciate if you could consider this change for inclusion in a future release. -------------- next part -------------- diff -ru rsync-2.6.3pre1/flist.c rsync-2.6.3pre1+tykhe/flist.c --- rsync-2.6.3pre1/flist.c 2004-08-12 14:20:07.000000000 -0400 +++ rsync-2.6.3pre1+tykhe/flist.c

Any votes for/against? ----- Forwarded message from Rik Faith <faith@alephnull.com> ----- Date: Wed, 28 Nov 2001 12:55:29 -0500 From: Rik Faith <faith@alephnull.com> To: mbp@samba.org Subject: rsync patch X-Mailer: VM 6.96; XEmacs 21.1; Linux 2.4.16 (light) Here is a patch that adds rate information (e.g., kB/s) to the --progress display. I just noticed that 2.4.7pre4 is coming

While trying out the 2.6.4-pre2, I noticed something wierd with --progress; it shows: ads/promotions.MYD 0 100% 0.00kB/s 519:35:46 (61, 56.3% of 597) This is quite reproducable whenever an empty file is transferred (or created on the receiving end). Commandline used was: rsync -zave 'ssh -c arcfour' --progress --stats --delete lisa:/var/lib/mysql/ . BTW, this also

Hello, When rsync'ing over an ISDN 64kb/s channel, I get reported mostly 0 kB/s: 1287 100% 0.00kB/s 0:00:00 home/httpd/html/mirrors/developer.apple.com/techpubs/macosx/System/Documentation/Developer/YellowBox/TasksAndConcepts/JavaTutorial/3.JavaDebugging/toc.html 731 100% 0.00kB/s 0:00:00

* Josh Coalson <xflac@yahoo.com> shaped the electrons to say... >yep, that will work too. but just writing skipping code is >pretty simple: > >is_last=0 >read 'fLaC' string >while (!is_last) { > read 1 byte metadata block type > read 3 byte metadata block length > is_last = type & 0x80 > fseek(file,length,SEEK_CUR) >}

* Josh Coalson <xflac@yahoo.com> shaped the electrons to say... >not exactly. the metadata interface won't tell you, but you >can create a decoder (say file decoder), set it up, then call > > FLAC__file_decoder_process_until_end_of_metadata(...) > FLAC__file_decoder_get_decode_position(...) > >and that will tell you. the decode position is relative to >the

Two patches follow this message. One fixes the default implementation of SEEK_HOLE/DATA. This patch applies atop Josef's last posted patch. The second patch implements the same on ocfs2. The test tool for the same is available here. http://oss.oracle.com/~smushran/seek_data/seek_test.c It is improved since the last post. It runs cleanly on zfs, ocfs2 and ext3 (default behavior). Users

Two patches follow this message. One fixes the default implementation of SEEK_HOLE/DATA. This patch applies atop Josef's last posted patch. The second patch implements the same on ocfs2. The test tool for the same is available here. http://oss.oracle.com/~smushran/seek_data/seek_test.c It is improved since the last post. It runs cleanly on zfs, ocfs2 and ext3 (default behavior). Users

--- Dan Sully <daniel@electricrain.com> wrote: > * Josh Coalson <xflac@yahoo.com> shaped the electrons to say... > > >not exactly. the metadata interface won't tell you, but you > >can create a decoder (say file decoder), set it up, then call > > > > FLAC__file_decoder_process_until_end_of_metadata(...) > >

I refer to a problem that appeared on the flac list last August that was either solved off-list or abandoned. (http://lists.xiph.org/pipermail/flac/2005-August/000468.html) The problem is with using the C++ encoder classes, particularly the FLAC::Encoder::File:set_metadata function. JC said that the developers version of how to add a simple metadata block looked right, but it did not work for

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 4) * Updated for committed robust_rename() patch, other changes in CVS. (rev 3) * Don't link empty files. * Roll over to new file when

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 3) * Don't link empty files. * Roll over to new file when filesystem maximum link count is reached. * If link fails for another reason, leave

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 5) * Fixed silly logic error. (rev 4) * Updated for committed robust_rename() patch, other changes in CVS. (rev 3) * Don't link empty

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 2) * This revision is actually against CVS HEAD (I didn't realize I was working from a stale rsync'd CVS). * Apply permissions after