On Fri, Dec 07, 2001 at 09:00:05AM -0600, Dave Dykstra <[EMAIL PROTECTED]> wrote: | 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()?
"nothing"! | 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. Right - this is what I would want. No lchown? Then down't test or change ownerships on symlinks. Likewise lchmod if these is such a beast. | 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? By reading the manual entries? Oh yeah, you're using configure :-( Ok, how in hell dows configure make such decisions now? Badly? | I think this is a can of worms, and we don't even know if it's going to | affect anybody. But we know that if it does affect somebody then the situation can be very bad indeed. And we also know that leaving symlinks the hell alone is pretty much harmless - they only need to point the right way - perms and ownerships are meaningless. What you want is some testing which comes out with a SAFE_CHOWN macro, which is _undefined_ if there's no lchown equivalent. Personally, for configure's purpose I'd be perfectly happy if "no lchown ==> no SAFE_CHOWN" because as remarked above, chowning symlinks is a waste of time. Then as you trip across platforms with a chown-that-doesn't-follow-symlinks you can have configure these weirdos on a case be case basis. The current situation does not fail safe. The "do nothing without lchwon" approach at least is safe, and loses no _useful_ functionality. -- Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/ The fortunate man knows how much he can safely leave to chance. - Lady Barbara Hornblower