similar to: wierd duration shown in progress with 0 byte files

A recent posting here got me thinking about having the --progress output tell the user about how many files were left to go in the transfer. I submit the attached patch which outputs an extra suffix onto the progress line at the end of each file's transfer (so it only appears once per file, not on every status update). The output would look like this: [...] flist.c 35671 100%

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

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,

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

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

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

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

* 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) >}

Le 21/08/2013 12:20, maximilian attems a ?crit : > On Tue, Aug 20, 2013 at 07:44:39AM +0200, leroy christophe wrote: >> Find attached two patches I have in order to build klibc 2.0.2 >> against kernel 3.8.13 >> We had to introduce those patches when going from kernel 3.6 to kernel 3.7 >> Hope it helps. >> > those patches are wrong and again very brittle. >

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

--- 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(...) > >

Dear all, I have made patch for samba-2.0.7/source/lib/bitmap.c With this patch 1) constant '32' is now named. 2) make only one malloc on bitmap_allocate(). ( This will make bitmap to fit within same page, which will cause lesser pagefault, I wish ) 3) totally changed bitmap_find(). I guess this should work faster then testing each bits one-by-one. ---

On (03/11/16 16:30), Minchan Kim wrote: > -static void *location_to_obj(struct page *page, unsigned long obj_idx) > +static void objidx_to_page_and_ofs(struct size_class *class, > + struct page *first_page, > + unsigned long obj_idx, > + struct page **obj_page, > + unsigned long *ofs_in_page) this looks big; 5 params, function "returning" both page and

On (03/11/16 16:30), Minchan Kim wrote: > -static void *location_to_obj(struct page *page, unsigned long obj_idx) > +static void objidx_to_page_and_ofs(struct size_class *class, > + struct page *first_page, > + unsigned long obj_idx, > + struct page **obj_page, > + unsigned long *ofs_in_page) this looks big; 5 params, function "returning" both page and

/* vixie crontab buffer overflow for RedHat Linux * * I dont think too many people know that redhat uses vixie crontab. * I didn''t find this, just exploited it. * * * Dave G. * <daveg@escape.com> * http://www.escape.com/~daveg * * */ #include <stdio.h> #include <sys/types.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #define

On Tue, Mar 15, 2016 at 03:40:53PM +0900, Sergey Senozhatsky wrote: > On (03/11/16 16:30), Minchan Kim wrote: > > -static void *location_to_obj(struct page *page, unsigned long obj_idx) > > +static void objidx_to_page_and_ofs(struct size_class *class, > > + struct page *first_page, > > + unsigned long obj_idx, > > + struct page **obj_page, > > +

Hello. I am trying to get the windows "previous versions" / shadow copies to work with our setup (samba+winbind over objectivefs). I have setup a test where I manually mounted two objectivefs snapshots in the /snapshots/ directory. Objectivefs filesystem is mounted on /ofs. When I try and look at the "previous version" in windows I get the error "there are no previous

On 2016/3/15 14:51, Minchan Kim wrote: > On Tue, Mar 15, 2016 at 03:40:53PM +0900, Sergey Senozhatsky wrote: >> On (03/11/16 16:30), Minchan Kim wrote: >>> -static void *location_to_obj(struct page *page, unsigned long obj_idx) >>> +static void objidx_to_page_and_ofs(struct size_class *class, >>> + struct page *first_page, >>> + unsigned long

On 2016/3/15 14:51, Minchan Kim wrote: > On Tue, Mar 15, 2016 at 03:40:53PM +0900, Sergey Senozhatsky wrote: >> On (03/11/16 16:30), Minchan Kim wrote: >>> -static void *location_to_obj(struct page *page, unsigned long obj_idx) >>> +static void objidx_to_page_and_ofs(struct size_class *class, >>> + struct page *first_page, >>> + unsigned long

-----Original Message----- From: Julio Cesar Esteves Cabezas [mailto:jcabezas at inovax.com.br] Sent: segunda-feira, 21 de maio de 2012 20:29 To: 'Conrad Parker' Subject: RE: [ogg-dev] Problems seeking with liboggz Hi, Attached goes MyAudio.spx. Julio. -----Original Message----- From: conrad.parker at gmail.com [mailto:conrad.parker at gmail.com] On Behalf Of Conrad Parker Sent: