From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8658 invoked by alias); 20 May 2009 14:42:47 -0000 Received: (qmail 8642 invoked by uid 22791); 20 May 2009 14:42:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 14:42:38 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E7A2E60B8007; Wed, 20 May 2009 15:42:34 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YagymHssIooP; Wed, 20 May 2009 15:42:33 +0100 (BST) Message-ID: <4A1416D1.10006@ecoscentric.com> Date: Wed, 20 May 2009 14:42:00 -0000 From: Ross Younger User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Gary Thomas CC: Bart Veer , ecos-devel@ecos.sourceware.org Subject: Re: Should hard links to directories work? References: <4A13F762.4050006@ecoscentric.com> <4A140B04.9050702@mlbassoc.com> In-Reply-To: <4A140B04.9050702@mlbassoc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00055.txt.bz2 Gary Thomas wrote: > What about "./." and "./.."? Those must certainly be allowed. What about them? They're supported in the standard way, though each filesystem does something different. ramfs adds links (via an internal mechanism) to . and .. when a directory is created, and does not appear to special-case them. It therefore seems plausible that you might unlink '..' - or even '.' if you were mad enough - and perhaps create fresh links pointing somewhere else. As mk_romfs builds up a filesystem it adds . and .. links to the output image in the conventional way, ignoring wherever they point on the filesystem it reads from. It also doesn't appear to check for directory hardlinks at all, anywhere, so if you do have a filesystem with such a hard link, it presumably won't be maintained in your output romfs. fatfs adds . and .. links when a directory is created, removes them when it is deleted, and doesn't allow link() anyway so you can't change them. jffs2 special-cases . and .. without making the links visible on-disk; a path element of '.' is simply consumed, and '..' goes to the parent node of the current node. (This is also what I've done in my YAFFS port.) So, in short, of the four filesystems currently in eCos, all afford '.' and '..' their usual behaviour by default. In three of them, this behaviour is fixed in the code; only one, ramfs, might allow you to get jiggy with them, but I haven't tested this and wouldn't want to. For a start, if you do touch '..', you risk getting very very confused, and perhaps breaking getcwd(). DDTT! Ross -- Embedded Software Engineer, eCosCentric Limited. Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK. Registered in England no. 4422071. www.ecoscentric.com