At Mon, 13 Feb 2006 22:06:53 +0600, Ivan Shmakov <[EMAIL PROTECTED]> wrote: > Actually, the DogCows problem exists in POSIX as well. Consider > the following example: > > $ ls -l foo/ > total 0 > -rw-r--r-- 1 ivan users 0 Feb 13 21:40 bar > -rw-r--r-- 1 ivan users 0 Feb 13 21:40 baz > $ > > Is the foo/ a directory? Of course it might be, but it's not > the case: > > $ ls -l foo > lrwxrwxrwx 1 ivan users 3 Feb 13 21:41 foo -> qux > $ > > In this example, `foo' acts as both the symbolic link and the > directory at the same time. The commands distinguish between > them (if there's a need to) by interpreting the trailing slash > as a request to dereference the symbolic link to the directory. > > Please note that the problem was solved by introduction of yet > another meaning for an already reserved slash character. Of > course, overusing the slash isn't probably a very good idea, but > it could be a practical solution for the simple cases. > > Furthermore, POSIX addresses this problem not only at the > ``shell level'', but at the level of the C Library as well (stat > () vs. lstat ()).
You make a good point. The introduction of symbolic links, a new type in the filesystem beside files and directories, in Unix had extensive ripple-effects through the interfaces, at the system level as well as at the shell level. Also, many programs needed to be adapted to deal correctly with the symbolic links. If the introduction of _one_ new type caused such large changes, it's not hard to see how the introduction of an infinite number of possible types can become unmanagable at the POSIX layer. > BTW, as long as the POSIX is ``emulated'' (as > opposed to ``implemented'') by the HURD, the particular case of > FileDir problem could probably be addressed by turning every > such FileDir into a symbolic link. This way, POSIX applications > won't probably get very confused. Not really, because that's not the semantics you usually want. > Introduction of yet another special character (or a string) seem > to me like a bad idea. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
