Very Computer

I'm not a ToolTalk guru by any account, so I really need some help here.

The Solaris 2 automounter is exceptionally clever, in that it uses the
loopback file system instead of symlinks when it sees that the file
system to be mounted is on the same machine as the mount point.  The
problem is, ToolTalk reads the /etc/mnttab file directly (according to
truss) in order to generate netfile paths, and (I suspect) fails to
acknowledge the loopback mounts.

Therefore, an entry of

    /export/home/rgm        /home/rgm       lofs  ...

generates a netfile path (via tt_host_file_netfile) of

    TTN0HOST=0-3,RPATH=4-12,LPATH=13-21:elko/home/rgm/home/rgm

instead of the correct netfile path of

    TTN0HOST=0-3,RPATH=4-19,LPATH=20-28:elko/export/home/rgm/home/rgm

Any suggestions?  I tried using a hostname_map to get the information
resolved on another machine (which would avoid the loopback mounts) but
it looks like tt_host_file_netfile ignores the hostname_map file.

Have I been running in circles because of a misconfigured ToolTalk
setup?  Is this an acknowledged (and hopefully patched) bug?  If not,
then is there any way to explicitly tell tt_host_file_netfile to return
a specified netfile path?

(This problem manifests itself in dtspcd, which is why I posted to
comp.unix.cde.  This also seems to be limited to Solaris 2, hence
comp.unix.solaris.)

Thanks in advance.

+I'm not a ToolTalk guru by any account, so I really need some help here.
+
+The Solaris 2 automounter is exceptionally clever, in that it uses the
+loopback file system instead of symlinks when it sees that the file
+system to be mounted is on the same machine as the mount point.  The
+problem is, ToolTalk reads the /etc/mnttab file directly (according to
+truss) in order to generate netfile paths, and (I suspect) fails to
+acknowledge the loopback mounts.
+
+Therefore, an entry of
+
+    /export/home/rgm        /home/rgm       lofs  ...
+
+generates a netfile path (via tt_host_file_netfile) of
+
+    TTN0HOST=0-3,RPATH=4-12,LPATH=13-21:elko/home/rgm/home/rgm
+
+instead of the correct netfile path of
+
+    TTN0HOST=0-3,RPATH=4-19,LPATH=20-28:elko/export/home/rgm/home/rgm

What OS version is this on?  The extra "/home/rgm" here looks
familiar, as if it might have been a bug I fixed in ToolTalk
for 2.6...

Where does the file you're interested in actually live in this
case?

Tooltalk knows how to deal with lofs.  I suspect the problem here
may be in dtspcd.  In fact I'm almost certain as I think about it.
I recall the engineers who made dtspcd ToolTalk-aware (it was IBM or HP)
clearly didn't have a full grasp of the calls they used.  I
thought there was at least one case where they were using the
wrong netfile conversion call for the  circumstances they were in.

+Any suggestions?  I tried using a hostname_map to get the information

As an aside I'll note that netfiles are supposed to be opaque tokens,
useful only for converting back to regular filenames via tt_netfile_file()...

+resolved on another machine (which would avoid the loopback mounts) but
+it looks like tt_host_file_netfile ignores the hostname_map file.
+
+Have I been running in circles because of a misconfigured ToolTalk
+setup?  Is this an acknowledged (and hopefully patched) bug?  If not,
+then is there any way to explicitly tell tt_host_file_netfile to return
+a specified netfile path?
+
+(This problem manifests itself in dtspcd, which is why I posted to
+comp.unix.cde.  This also seems to be limited to Solaris 2, hence
+comp.unix.solaris.)

So you've looked at the dtspcd src to confirm this?

I fixed several bugs in dtspcd for 2.6 that had to do with
using the wrong paths for remote execution, and also there were
other problems caused by poor memory management in dtspcd.  If
you're  running pre 2.6 you may be running into  those bugs.  A
patch was released  for at least some of of those bugs in pre 1.2
CDE.

Robert

Robert