From owner-freebsd-current Sat Jun 16 11:45:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id F400937B409 for ; Sat, 16 Jun 2001 11:45:42 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5GIjXl01077; Sat, 16 Jun 2001 11:45:33 -0700 (PDT) (envelope-from dillon) Date: Sat, 16 Jun 2001 11:45:33 -0700 (PDT) From: Matt Dillon Message-Id: <200106161845.f5GIjXl01077@earth.backplane.com> To: Poul-Henning Kamp Cc: Jordan Hubbard , bde@zeta.org.au, steveo@eircom.net, david@catwhisker.org, current@FreeBSD.ORG Subject: Re: symlink(2) [Was: Re: tcsh.cat] References: <89423.992715599@critter> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :... :> :>True. It would break phk's malloc debugging features to disable this, :>for example. : :Not only that, but considerning that a symlink can point into a :different filesystem even in normal use, there is no simple way to :validate the valididty of the name. ... or be associated with a chroot situation and simply not resolve when accessed outside of the chroot. At BEST we had symlinks on the server that crossed NFS boundries on the client, for example. From the server's point of view they went off into empty space. Or a thousand other things. We should let this this thread die now. I think it's fairly clear that symlinks should not be messed with. cp's handling of symlinks is another, unrelated matter. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message