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
