On Wed, Nov 19, 2008 at 7:36 PM, Francisco J Ballesteros <[EMAIL PROTECTED]> wrote: > BTW, I´d love to hear other experiences regarding ns or path reconstruction.
i wrote a reverse path evaluator (ftrans) for inferno - given a path, it uses fd2path and /prog/xx/ns to attempt to return the originally mounted path. the reason for implementing it was to make it easier to generate paths to be used externally, in particular for the os(1) command. it gives a certain amount of freedom to re-bind paths locally to make convenient aliases without needing to modify all the software to take account of the new convention. obviously there are many cases where it's not possible (e.g. where two directories from the same filesystem are union-bound together), but it does work ok. in cases where the bind is ambiguous, it stats ancestors of the file and disambiguates by looking at the device letter (it'd be useful if ns provided the dev number of the mounted file, as well as the device letter). it punts on actual mounts - there's nothing useful you can do programmatically with a mount ns entry, you can't re-mount it, and ns doesn't record how the original Chan was generated (that's not true in plan 9, where you can remount the #s entry, of course). instead, it takes an association list of "stop paths" - paths where it stops the search and returns the associated answer. this means that where a particular path is ambiguous, or unresolvable (e.g. mount kremvax /n/krem), we can associate that path with the desired outcome, if there is one.
