On Sun 19 Mar 2006, martin f krafft wrote: > also sprach Paul Slootman <[EMAIL PROTECTED]> [2006.03.19.1444 +0100]: > > > It needs not use all metadata at all times. If I don't requiest > > > e.g. permissions to be synchronised, it should not compare > > > permissions. Or from a different angle: if two files are > > > identical except for the permission bits, but my rsync call does > > > *not* specify > > > > How is it to know that the two files are identical in that case? > > How does it know they are identical in the forth run of rsync in the > original post, after the permissions had been synchronised too? > stat() structures can be equal for different files...
Yes, but that's the design decision for rsync, which is overridable with --checksum. You're asking for the check to become _more_ prone to errors. BTW: rsync uses file size and timestamp, owner and permissions don't come into it; sorry for the misunderstanding. So all you need added to your -r is -t to prevent the checksums. You still didn't answer my question: How is it to know that the two files are identical in that case? You're assuming it can know this in your argument, please explain that part. If you can't, the rest doesn't hold much water either. > > > Right. I know. The point is that rsync could be a little smarter > > > at deciding when it actually has to use the rolling checksum. > > > For instance, by checksumming the whole file first before > > > rolling over it. > > > > You think the rolling checksum is less efficient than checksumming > > the whole file? Perhaps, but I wonder whether it's measurable, > > It certainly takes longer. Duh. But how much? 0.01% perhaps? I don't know, but I expect it's hardly noticeable, and as I said: > > especially given the fact that if there *is* a difference, it > > needs to redo the checksum and IO the two files in question again > > totally when it finds a difference. I'd like to see some analysis So it's only useful when you *know* that files will be identical in 99.9% of the case. And: the --checksum option does exactly what you ask, I believe, unless I've misunderstood you. > > of how inefficent the rolling checksum is... > > True. > > I have two huge directories with complex permissions. I always rsync > from one to the other. Previously, I used to set the permissions on > the source before rsync'ing with -a. Whenever I forgot to set the > permissions locally, things would screw up. > > Therefore, we set umasks and setgid correctly all over the target > tree, and use -r now for the synchronisation. But this takes almost > half an hour even if the source hasn't changed since the last sync. > It used to take less than a minute when we used -a. I don't see how that's worse than the "things would screw up" when the permissions were not set beforehand, rsync without a previous -a (or -t) invocation will do the same thing in that circumstance. > > -- > .''`. martin f. krafft <[EMAIL PROTECTED]> > : :' : proud Debian developer and author: http://debiansystem.info > `. `'` > `- Debian - when you have better things to do than fixing a system > > Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! > > "si tu veux construire un bateau, il ne faut pas réunir des hommes > pour aller chercher le bois et les outils et les préparer à se > répartir les différents travaux. Il faut plutôt leur donner l'envie, > la passion de la mer infinie." > -- antoine de saint-exupéry This signature is a bit over the top, isn't it. Especially when it will get repeated into the BTS log for every reply... Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
