Has anyone ever seen this happen when using rsync ? I'm trying to send a
series of =~ 300k files down the line, but for some reason, rsync thinks
each file is 17592186044416 bytes long! The same behaviour occurs when
using rsync to copy files locally.
Partial output follows...any help appreciated!
I am truly enjoying my rebirth. No more excuses, no more frustration,
no more having to solely satisfy my girlfriend orally.
I just pop 10 mg, and before long, I am a sex machine.
Now that I can get rock-hard again, my girlfriend can enjoy her favorite position:
being on top, which is difficult fo
You could probably put in some form of progress meter into your "rsh"
(defaults to ssh) command.
I've attached my "reblock" command, which is somewhat similar to dd, but
with the -t option it counts the number of kilobytes transmitted, as
well as giving two throughput measures.
reblock could eas
On Mon, Sep 27, 2004 at 03:18:12PM -0400, Full Decent wrote:
> I think this largely inaccurate representation would be useful for
> something like, say, the gentoo portage tree.
Hmm, yes, I used gentoo for a while, and having a huge collection of
small files would be one case where an indication o
On Sat, Sep 25, 2004 at 11:53:48AM -0400, Full Decent wrote:
> Is it functionally possible to have only one simple progress bar
> represent the whole rsync operation?
You could have a percent represent how far in the file list we are, but
that is a very inaccurate indication of how much work is to
On Fri, Sep 24, 2004 at 03:47:03PM +0200, Paul Slootman wrote:
> If I then run it again, I get the following [a different hashed file]
I didn't see that in my just-run test. I did notice a problem with the
code not removing an existing destination file prior to trying to hard
link a hashed file i
