public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Ross Younger <wry@ecoscentric.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: Bart Veer <bartv@ecoscentric.com>, ecos-devel@ecos.sourceware.org
Subject: Re: Should hard links to directories work?
Date: Wed, 20 May 2009 14:42:00 -0000	[thread overview]
Message-ID: <4A1416D1.10006@ecoscentric.com> (raw)
In-Reply-To: <4A140B04.9050702@mlbassoc.com>

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

  reply	other threads:[~2009-05-20 14:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-20 12:28 Ross Younger
2009-05-20 13:45 ` Bart Veer
2009-05-20 13:52   ` Gary Thomas
2009-05-20 14:42     ` Ross Younger [this message]
2009-05-20 16:56   ` Jonathan Larmour
2009-05-20 14:21 sandeep
2009-05-20 14:47 ` Ross Younger
2009-05-20 16:00 ` Rutger Hofman
2009-05-20 16:35   ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A1416D1.10006@ecoscentric.com \
    --to=wry@ecoscentric.com \
    --cc=bartv@ecoscentric.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=gary@mlbassoc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).