Date: Tue, 7 Jul 1998 06:25:57 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rivers@dignus.com (Thomas David Rivers) Cc: mike@smith.net.au, rivers@dignus.com, drosih@rpi.edu, hackers@FreeBSD.ORG, wjw@surf.IAE.nl Subject: Re: Variant Link implementation, continued Message-ID: <199807070625.XAA02268@usr06.primenet.com> In-Reply-To: <199807061332.JAA26291@lakes.dignus.com> from "Thomas David Rivers" at Jul 6, 98 09:32:48 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Seems reasonable... [and, nope, I don't have file names like that, > fortunately :-)]. > > However, can someone with the POSIX spec in-hand speak to the POSIX > ramifications here? I mean, if we essentially "steal" this space, > does it break any (future) POSIX conformance? Is "SOLO" good enough? Do you need specific rationale quoted? It's pretty obvious from context that the POSIX namespace doesn't apply below the system call (or library) impelementation of the POSIX interface, so long as the time update guarantees aren't affected by the implementation. The POSIX namespace escape is a dual "/" prefix. FreeBSD, of course, buggers this up, because it can't inherit the namespace escape down multiple iterations of path components; for example: //apple_hfs_semantic:rsrc/<some path>, where somepath: relative_path | absolute_path To access the resource fork of a file. This means that the escape is one path component, which is inadequate. The problem is in: 1) The use of mutual recustion to allow expansion into the path buffer (which also leads to prematurely reaching the MAXPATHLEN -- 1024 -- limit on some types of relative symlink expansion). 2) The non-opacity of the cn_pathbuf, et. al. values to the underlying FS, making it impossible to seperate an escaped lookup from an unescaped lookup. 3) The lack of a third "void *" context component for implementing various escape mechanisms. 4) The reset of the root because of the leading "/", even though it is part of the "//" token which is a namespace escape introducer. Of course, other OS's have also peed in the pool: I. Any Microsoft OS takes the "//" to mean "escape to the LanMan namespace", which is bogus as hell, since it leaves no room for other namespaces (perhaps this was their intent, but I prefer to ascribe it to stupidity). II. Intel Xenix, and similar OS's (such as PrimeOS using the Touch Communications, Inc. implementation) implementing Intel's "OpenNET", which implys the "//" to mean "escape to the OpenNET namespace" -- similarly bogus as hell. So at least we're not alone. The POSIX question boils down to whether or not you are permitted to implement a non-POSIX namespace in a POSIX system call. The technical anser is "no, but...". Because the expansion occurs at link expansion time, then the component reported to the POSIX evaluation of a path that contains a symlink that contains a variant target... is defined by the FS. This means that variant links are allowed. If you wanted to get entirely anal, you could always insist on a link target for a variant link beginning with: "//variant_link_semantic:freebsd/<the variant symlink>" But I think you can justify ommitting this prefix through the readlink(2)/symlink(2) "undefined" behaviours. After all, whose to say that the the implementation defined behaviour is not "variant links at all times". 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807070625.XAA02268>