Namespace junctions are another example of the hidden server effect. The following remote filename was discussed earlier:
/.../tinseltown.org/fs/doc/jones/app.gd/chap2.ps
There it was explained that doc/jones/app.gd/chap2.ps is an entry in DCE DFS's own namespace, while /.../tinseltown.org/fs is a DCE namespace entry. Suppose a user enters the following:
ls -l /.../tinseltown.org/fs/doc/jones/app.gd
The clerk agent program (called as a result of the user's entering ls) will bind to the remote file server via its /.../tinseltown.org/fs DCE namespace entry, and pass to it the residual DFS entry name doc/jones/app.gd along with other parameters. The ls command behaves this way because the underlying (VFS+ layer) system calls are coded that way. The DFS server then performs the request (note that the details of interaction within DFS are somewhat more complex than implied by this description). The user only types the command line; the rest is done by DCE, and a directory listing appears on the user's screen.
Because the VFS+ system routines, which are used by all possible clients of DFS services (for example, commands like ls and rm, library routines like fopen( ) and fclose( )), know about the remote file server at /.../tinseltown.org/fs and bind to it correctly, the transition from the DCE to the DFS namespace is completely transparent to users. And this is how junctions work. As long as all possible clients behave correctly with a name that includes a junction, the junction will not be perceptible to the clients' users.
More: