From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 29 08:21:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95E721065674; Fri, 29 Jul 2011 08:21:47 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 597238FC13; Fri, 29 Jul 2011 08:21:47 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p6T8LQAQ019793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jul 2011 01:21:27 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p6T8LQ5m019792; Fri, 29 Jul 2011 01:21:26 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA09513; Fri, 29 Jul 11 01:17:14 PDT Date: Fri, 29 Jul 2011 08:17:21 -0700 From: perryh@pluto.rain.com To: jang@ioctl.org, jan.grant@bristol.ac.uk Message-Id: <4e32cf01.R6F64Wsxhnb+t0xb%perryh@pluto.rain.com> References: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, rwatson@freebsd.org, s@samu.pl Subject: Re: Finding symlink information in MAC Framework X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 08:21:47 -0000 jan.grant@bristol.ac.uk wrote: > On Wed, 27 Jul 2011, perryh@pluto.rain.com wrote: ... > One additional thing that symlinks manage to do is to refer to > directories as well as files Yes; I left that aspect out by way of simplification since it did not seem pertinent to the OP's situation. > hard links to directories spawn problems such as requiring garbage > collection and smarter filesystem descent algorithms, which is > another reason they're typically prohibited except in the case > where they're created by "mkdir". or by "mv", when moving a directory within the same physical filesystem. The two biggest problems I'm aware of are: * They create the possibility that the filesystem is no longer a tree but a more general directed graph which may even be cyclic. The possibility of a cyclic graph would indeed require handling in utilities such as find(1) and "ls -R", but the only case I've thought of that would need garbage collection -- as opposed to some minor extension of the current reference-counting scheme -- would be detection of cycles that have become disconnected (unreachable from either the root or any currently-open directory). However, I think prohibition of hard-links to directories is not sufficient to prevent the creation of isolated cycles. Consider: $ mkdir -p /tmp/a/b/c/d/e/f/g $ cd /tmp/a/b/c/d/e $ mv /tmp/a/b f/g Unless either mv or the kernel goes to some trouble to detect the subterfuge, this will create an isolated cycle f/g/b/c/d/e/f/... * Where should my .. entry point, if links to me (other than my . entry and my subdirectories' .. entries) appear in more than one directory? > FWIW one of the early unix systems I was exposed to permitted the > creation of hard links by arbitrary users. Just _one_? I've never heard of any that did _not_ permit that! (AFAIK Posix requires it.)