Re: bug in permissions on symlinks
| Does anybody run rsync on Apollo? Hell, they run it on Windoze :-( I know what I'd rather use. Huh? In stead of Windows, or in stead of rsync? :) There's a lot of Windows-users out there, and I think rsync is a great tool on Windows-systems too. :) No OS-wars here, just wanted to know if you are thinking of a better tool for Windows, or a better OS for rsync... :) /Niels Andersen
Re: move rsync development tree to BitKeeper?
Incidentally, here's an interesting BitKeeper demostration/tutorial: http://www.bitkeeper.com/demo/ -- Martin
Re: bug in permissions on symlinks
On Fri, Dec 07, 2001 at 10:56:17AM +0100, Niels Andersen [EMAIL PROTECTED] wrote: | | Does anybody run rsync on Apollo? | Hell, they run it on Windoze :-( I know what I'd rather use. | Huh? In stead of Windows, or in stead of rsync? :) | | There's a lot of Windows-users out there, and I think rsync is a great tool | on Windows-systems too. :) | | No OS-wars here, just wanted to know if you are thinking of a better tool | for Windows, or a better OS for rsync... :) The latter. It was somewhat on the lines of they run it on windows - _surely_ someone runs it on an Apollo, or will. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Machine, you are about to be lobotomised, please don't take it personally. It happens to the best of us. Then they become managers. - [EMAIL PROTECTED] (Peter Evans)
Re: bug in permissions on symlinks
On 7 Dec 2001, Cameron Simpson [EMAIL PROTECTED] wrote: Please don't take this path - ownerships on symlinks are a pretty meaningless concept Right. For just this reason I just changed the regression test to use an included tiny ls, rather than the system's ls, because on some systems the permissions and ownership it reports for symlinks can be randomly wierd. For example, on FreeBSD the perm bits on a symlink are set to 0777 ~umask, but they can't be chmodded and they have no effect on its behaviour. Havoc for test cases that try to diff two directory listings! Why _not_ take the conservation approach unless somebody reports a problem [sic]? I'll speak to tridge, but I think we should pull this line out because of the scenario Cameron describes. -- Martin (Now on ZX12-R)
Re: Cosmetic code cleanup?
On 6 Dec 2001, Jos Backus [EMAIL PROTECTED] wrote: Here's a list of cosmetic changes I'd be willing to make to the code in order to make it more consistent, which stylisticly it currently is not. - separate function definitions by 2 newlines - put spaces after commas in arg lists - put spaces around assignments - remove trailing spaces - change space indents to tabs - fix multiline comments - remove redundant /* dw */ comments (Deborah Weiss is already - credited in the documentation) Yes, I agree. I'll just run GNU indent over it and commit directly -- no need to send a big noisy patch unless you really want to. -- Martin
Re: bug in permissions on symlinks
On Sat, Dec 08, 2001 at 12:05:44AM +1100, Martin Pool wrote: On 7 Dec 2001, Cameron Simpson [EMAIL PROTECTED] wrote: Please don't take this path - ownerships on symlinks are a pretty meaningless concept ... Why _not_ take the conservation approach unless somebody reports a problem [sic]? I'll speak to tridge, but I think we should pull this line out because of the scenario Cameron describes. You can't just delete the #define, because the rsync code uses lchown() throughout. If you're on a system that doesn't have lchown(), what else are you going to use other than chown()? If you want to avoid a problem, the only thing you can do is to make sure that rsync never attempts to change the ownership on a symlink when that will cause a problem. I just verified on Solaris that rsync is in fact doing an lchown() on a symlink when the owner/group doesn't match. If you want to solve this problem correctly, it's also not enough to just do an #ifndef HAVE_LCHOWN either, because as I found out, on some systems chown() does the right thing. You'd need a new configure test to find out whether or not chown does the right thing on a symlink. However, a lot of systems allow only the super-user to do a chown, so how are you going to test it? I think this is a can of worms, and we don't even know if it's going to affect anybody. - Dave
Re: protocol error?
On Fri, Dec 07, 2001 at 12:02:35PM +0900, [EMAIL PROTECTED] wrote: I recently upgraded one of my servers to 2.5.0. Since then, I've been getting error messages like following between 2.5.0 and 2.4.6 servers. bit length overflow code 3 bits 7-6 code 10 bits 5-6 Does this error come from using different protocol version? Regards, Hori Masato Software Engineer Sony Corporation I haven't seen it myself, but several other people have reported it and the conclusion so far is that they are harmless messages from the zlib library. A quick glance at the code looks like they should only be printed if DEBUG is defined and -v is passed. I see that DEBUG is turned on now by configure by the --enable-debug option, and it's default is yes. According to rsync's cvsweb, the --enable-debug configure option was added last February which means it's new in the 2.5.0 release. My guess is these bit length overflows were always happening but nobody noticed it because the DEBUG mode wasn't turned on. Martin, I don't think --enable-debug should define #DEBUG, I think it should only generate debugging symbols. - Dave Dykstra
Re: bug in permissions on symlinks
The only circumstance where i could see symlink ownership being an issue would be in the case where one might need to be changed, on those systems which support that. Most i've seen delete and recreate the link, so if the person needing to own the link has write, with no sticky bit, on the containing directory,, he's good to go. Can anyone see another issue? Certainly, the whole inane follow-link behaviour of chown and chmod are big traps. I was shocked to see a chown down a users directory tree on solaris make him the owner of many system files on the system i did it from (nfs user dirs), and won't make the same mistake twice. If rsync isn't going to have predictable behaviour on chowning (chmodding too, on some systems), perhaps we should let it leave ownerships and modes on symlinks at the system default. Scenario: I have an account on a system being backed up to another system, with rsync. I link /etc/security/password (or /etc/shadow/password, or /etc/shadow) into my tree. i get backed up. I go to the other system. I edit /etc/passwd, since it now belongs to me, moving my password into root's password field ( saving the old one so i can cover my tracks). I log in as root. I do what I want. I put the password back and fix the ownership. I log back out of root. If rsync gets a lchown or sensible chown, this won't happen, if it doesn't, it could. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim?
using uid instead of USER or LOGNAME
Are there any known patches to use a users effective uid rather than the environment variables USER or LOGNAME with an rsync server. Any suggestions would be appreciated. _Brian Brian Holstein Sysadmin SLK Hull derivatives
RE: move rsync development tree to BitKeeper?
You can find a lot more information about the differences here: http://bitkeeper.com/4.1.1.html BitKeeper is not strictly Open Source, but arguably good enough. I guess arguably is if you don't mind having all your metadata logged to an open logging server? The proposed plan is to convert the existing repository, retaining all history, some time in December. At this point CVS will become read-only and retain historical versions. I'm curious at the driving force here? You talk about switching, but don't really mention much about why - other than to get feet wet before using it for other projects. So is it really the other projects that have specific needs? Is there specific functionality lacking in CVS that is trying to be fixed? At least for me, CVS is more convenient since it works will all the open projects I use (and yeah, is easier in terms of licensing). I don't have strong objections to a change, but as one user who does tend to track the source tree and not just releases, I definitely would prefer to continue to see (as you did suggest) alternative access to the current source tree (even if only daily snapshots), since at least for me rsync would be the only BK project I'd care about - it's not clear I'd want to bother with the client. -- David /---\ \ David Bolen\ E-mail: [EMAIL PROTECTED] / | FitLinxx, Inc.\ Phone: (203) 708-5192| / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \---/
