https://bugzilla.samba.org/show_bug.cgi?id=2408
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
On Sat, Mar 05, 2005 at 05:54:28PM -0800, Frederik Eaton wrote:
> It breaks some functionality of the
> --include and --exclude options:
True. You can work around that problem if you always use an '=' to
connect the option to its arg by adding a new match to the case in that
function:
--excl
https://bugzilla.samba.org/show_bug.cgi?id=2328
--- Additional Comments From [EMAIL PROTECTED] 2005-03-05 20:19 ---
(In reply to comment #0)
See also http://www.cygwin.com/ml/cygwin/2003-10/msg00129.html
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--
> > In which case, do you have boilerplate shell code which parses rsync
> > command lines (or is there such code included in the distribution for
> > easy update in case the argument syntax changes)? It seems non-trivial
> > to me.
>
> It's not needed. No option name ends in "/", so the function
On Sat, Mar 05, 2005 at 01:25:26PM -0800, Frederik Eaton wrote:
> In which case, do you have boilerplate shell code which parses rsync
> command lines (or is there such code included in the distribution for
> easy update in case the argument syntax changes)? It seems non-trivial
> to me.
It's not
On Sat, Mar 05, 2005 at 12:46:57PM -0800, Wayne Davison wrote:
> On Sat, Mar 05, 2005 at 12:33:27AM -0800, Frederik Eaton wrote:
> > what would be nicer is an option to turn off the special
> > interepretation of terminal slashes in source paths.
>
> That would be easy enough to do in a shell func
On Thu, Feb 24, 2005 at 03:09:03PM -0600, chris allen wrote:
> What it be better to run the rsync command on the backup server or the
> live server to save bandwith on the live server?
If I understand you correctly, you're copying files betweeen machine A
and B and you want to know if you should i
On Sat, Mar 05, 2005 at 10:58:12PM +0200, Shachar Shemesh wrote:
> What about my proposal, though? Should I send in a patch so it can be
> evaluated (hoping I'll manage to find my way around, that is).
I'm always open potential patches. If we can make things faster without
taking up large chunks
On Sat, Mar 05, 2005 at 06:53:08AM -0800, Lawrence Wong wrote:
> # rsync -av --stats --delete --force
> ftp.funet.fi::CPAN
Hmm, there's no destination directory specified there. Did you omit it?
Or are you doing a file listing?
> rsync: connection unexpectedly closed (9382362 bytes received so f
Wayne Davison wrote:
But how will you find it there? If you are going to have 740K blocks
(i.e. - 740,000 strong hashes) in a 16bit hash table, you are going to
have lots of collisions there (190 per bucket, on average), and you
gained nothing.
You'll note that a no-match bitmap has no effe
On Sat, Mar 05, 2005 at 12:33:27AM -0800, Frederik Eaton wrote:
> what would be nicer is an option to turn off the special
> interepretation of terminal slashes in source paths.
That would be easy enough to do in a shell function that you could use
to wrap up your rsync invocations. It would scan
On Sat, Mar 05, 2005 at 08:07:20PM +0200, Shachar Shemesh wrote:
> Definitely not [block-size]! I was talking about the hash table load.
Ah yes, I can see that I misread what the "it" was referring to. Thanks
for the clarification.
> But [the bitmap lookup] only works if the checksum function a
> Wayne Davison wrote:
> >He's talking about potentially losing an even distribution of values
> >if the lowest order bits aren't random enough.
On Sat, Mar 05, 2005 at 08:10:37PM +0200, Shachar Shemesh wrote:
> Even for N which is not a power of 2?
In the case of the weak checksum, it is compute
On Sat, Mar 05, 2005 at 07:44:06PM +0100, Paul Slootman wrote:
> the else branch of the if did a "diff ? bla /diff : 0"
Yeah, my patch also changed that to make it consistent (but I didn't
mention it in my email). I believe that in the else branch it is
impossible for diff to ever be 0 (which is
On Sat 05 Mar 2005, Wayne Davison wrote:
> > I don't quite see the point of setting diff to 1ms if it's zero...
> Because an elapsed time of 0 means that any data that arrived, arrived
> very quickly. Setting the rate to 0 when the elapsed time is 0 is the
> opposite of what we need -- an infini
Wayne Davison wrote:
On Sat, Mar 05, 2005 at 02:18:01PM +0200, Shachar Shemesh wrote:
However, if you choose to start with the 32 bit rolling hash and mod
that, you will have problems. The rolling checksum has two distinct
parts, and modding will only pull info from the low order bits,
Wayne Davison wrote:
On Thu, Mar 03, 2005 at 10:18:01AM +0200, Shachar Shemesh wrote:
And I'm suggesting making it static, by adjusting the hash table's
size according to the number of blocks.
The block-size?
Definitely not! I was talking about the hash table load. I.e. - the
ratio bet
On Fri, Mar 04, 2005 at 11:13:22PM +0100, Paul Slootman wrote:
>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).
This is caused by the ph_start.time value being 0 for a 0-length
[I accidentally sent this reply only to Lars instead of the list.]
On Fri, Mar 04, 2005 at 06:44:48PM +0100, Lars Karlslund wrote:
> I read somewhere about the default blocksize of 700 bytes. Now I'm
> told the blocksize is calculated automatically. Which is it?
700 is the minimum block-size. Th
On Thu, Mar 03, 2005 at 10:18:01AM +0200, Shachar Shemesh wrote:
> And I'm suggesting making it static, by adjusting the hash table's
> size according to the number of blocks.
The block-size? No thanks. The smaller the block-size for a particular
file size, the more checksum data needs to be gen
On Sat, Mar 05, 2005 at 02:18:01PM +0200, Shachar Shemesh wrote:
> That's not what I read into it. It seems to me that the checksum
> function gives a 32bit result, and we are squashing that into a 16bit
> hash table. Can you point me to the code? Wayne?
Look in match.c. The hash table is "tag_
On Wednesday 02 March 2005 06:11 pm, Scott Becker wrote:
> I've been researching the state of 'file alteration monitoring'
> technology on Linux. Famd uses dnotify to inefficently monitor a handful
> of directories. The replacement for dnotify is being worked on in the
> kenel and it's called inoti
Hi everyone,
Previously I was using RSYNC 2.5.7 on RedHat 8.0 to
mirror CPAN (http://www.cpan.org/) and LDP
(http://www.tldp.org/) and everything was working
fine.
After upgrading to Fedora Core 2 and using RSYNC 2.6.x
, I kept on getting the following errors:
# rsync -av --stats --delete --for
Kevin Day wrote:
As a quick FYI, the block size absolutely has an impact on the
effectiveness of the checksum table - larger blocks means fewer
blocks, which means fewer hash colissions.
Since you wouldn't expect that many blocks in the file, a 32bit weak
checksum would only produce about 4 or 5
Lars Karlslund wrote:
And I'm suggesting making it static, by adjusting the hash table's size
according to the number of blocks. Just do
"hashtablesize=(numblocks/8+1)*10;", and you should be set.
Or maybe it should really be dynamic.
I'm talking about the hash table load. I.e. - the ratio b
(Email attachment quoted for the benefit of the mail archive...)
On Thu, 3 Mar 2005, michael mendoza <[EMAIL PROTECTED]> wrote:
>
> Hi, thank again.
>
> I used rsync today to copy 400 MB from a pc to other
> pc with rsync -avz -e ssh SourceDir
> [EMAIL PROTECTED]:/dirDest/
>
> but in the source
One of my pet peeves with rsync is that I too often end up writing
1. rsync a/ h:
when I meant
2. rsync a h:
This is because my shell leaves the trailing slash when I complete
directories. I'm not going to reconfigure my shell just for rsync -
besides, I like the trailing slash as a visual indi
27 matches
Mail list logo
