https://bugzilla.samba.org/show_bug.cgi?id=5478
--- Comment #19 from Eric Shubert 2011-10-06 15:28:32 UTC ---
(In reply to comment #14)
> So, looking at your trace, it looks like the sender is waiting to write more
> data (its select lists the write and error FDs). The receiving side's 2 pids
>
I appreciate the suggestions so far but I know how to measure usage with
'du' et al. The hitch here is that I want to exclude files the
--filter='dir-merge .rsync-filter' excludes. Hense the thought to use rsync
itself.
On Oct 6, 2011 11:02 AM, "K S Braunsdorf" wrote:
>>that processes any filter f
https://bugzilla.samba.org/show_bug.cgi?id=8090
Wayne Davison changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Wayne Davison
https://bugzilla.samba.org/show_bug.cgi?id=8508
--- Comment #3 from Wayne Davison 2011-10-06 15:55:44 UTC ---
The asprintf() call in question is only 1 of 2 in all of rsync that tests the
success of the function via "<= 0" rather than "< 0". Perhaps just removing
the '=' in those calls would fix
On Thu, 6 Oct 2011, Paul Dugas wrote:
I appreciate the suggestions so far but I know how to measure usage
with 'du' et al. The hitch here is that I want to exclude files the
--filter='dir-merge .rsync-filter' excludes. Hense the thought to use
rsync itself.
It sounds like you missed the poin
On Thu, Oct 6, 2011 at 1:01 PM, Benjamin R. Haskell wrote:
> use your rsync command with '--list-only', and post-process that list.
>
Even easier, just make a note of the verbose output from the copy (get
better stats via --stats with or w/o --verbose). Or, if you need a special
run, --dry-run (
On Thu, 6 Oct 2011, Wayne Davison wrote:
On Thu, Oct 6, 2011 at 1:01 PM, Benjamin R. Haskell wrote:
use your rsync command with '--list-only', and post-process that list.
Even easier, just make a note of the verbose output from the copy (get
better stats via --stats with or w/o --verbose).
On Thu, Oct 6, 2011 at 4:01 PM, Benjamin R. Haskell wrote:
> It sounds like you missed the point of Kevin's message (in the other fork of
> this thread). The point wasn't to use
> `du`, it was that you can run your stats against the backed-up files, not the
> source. Then you're only running s
>> It sounds like you missed the point of Kevin's message (in the other fork of
>> this thread). The point wasn't to use
>> `du`, it was that you can run your stats against the backed-up files, not
>> the source. Then you're only running stats
>> against the results of running the backup using
