This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should hard links to directories work?

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!


Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.        

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]