Summary:: Update: mount directory mount point

Thanks to Dr.Blinn for clearifying that the remedy that
I first requested was not so simple. I got notification
from the departments involved that they will change their
scripts, but still requested my workaround in the interem.
I dont anticipate that the /local/bin/pwd tcsh script will
break anything, but you never know.

Thanks much.

Bugs

Operating Systems Analyst for unix systems
Humboldt State Univ.	Information Technology Services
Arcata, Calif.

email [email protected]

---------- Forwarded message ----------
From: "Dr [email protected]" <[email protected]>

Very clear explanation.  Alas, Tru64 UNIX doesn't have the same
features in this area as Linux.

You could, in principle, replace /bin/pwd (assuming that that's
used universally) with a script or program that knows that if
it can find a symlink by stripping off /home that leads to the
current directory, it should display the path by stripping off
that much of the leading path.  But that's bizarre..

The right fix is really to change the things that are checking
for the absolute path to know a list of valid paths, but that
would have been easier up front, and no one anticipated this
change in layouts.

There is no simple solution to the problem.  The approach you
used of having the symlink from the old location that leads to
the real new location is very much the "UNIX way", but there
are cases (pwd notably) where that doesn't work, and what an
application really wants to know is either (a) how it got to
where it presently is, that is, more or less what "cwd" does
in some shells, or (b) the simplest path that gets it to its
current real location from the root, even if that path is by
use of a symbolic link instead of a real directory tree.

Since this is an application problem, it's really up to the
applications (e.g., scripts) to solve it.  You can offer a
few ways that help, but there's no simple method to make it
totally transparent, at least none that I know of on Tru64
UNIX.

Tom

> I have been requested to make myself more clear, and
> give my problem rather than ask for a solution.
> I appologize for my vagueness.
>
> We just migrated a server from an alpha 2100 (hostA)
> to an ES40 (hostB).
> There were 4 filesystems on hostA that were placed as
> subdirectories on hostB:
> hostA:
> df
> /dev/disk/dsk1g      5878109     2759618     2824585    50%    /u
> /dev/disk/dsk4g     12183434     7872959     3701303    69%    /bhome1
> /dev/disk/dsk8g     12183434     3461371     7503719    32%    /ohome1
> /dev/disk/dsk9g      8057740     4838990     2815863    64%    /tech
>
> hostB:
> df
> laurel#home        54730624    19492349    35113288    36%    /home
>
> cd /home
> ls -l
> drwxr-xr-x   8 root     system      8192 Sep  8  2004 bhome1/
> drwxr-xr-x   6 root     system      8192 Dec 16  2003 ohome1/
> drwxr-xr-x   7 root     system      8192 Dec 16  2003 tech/
> drwxr-xr-x 140 root     system      8192 May 31 09:14 u/
>
> On hostB, I created sym links so software would not break:
> cd /
> l1 -l
> lrwxrwxrwx   1 root     system         12 Oct 28  2004 bhome1@ -> /home/bhome1/
> lrwxrwxrwx   1 root     system         12 Oct 28  2004 ohome1@ -> /home/ohome1/
> lrwxrwxrwx   1 root     system         10 Oct 28  2004 tech@ -> /home/tech/
> lrwxrwxrwx   1 root     system          7 Oct 28  2004 u@ -> /home/u/
>
> The only thing that fails, is that some departments run nitely jobs
> that test for "pwd", and it must equal what they expect to find
> such as /u/jobs/bin. Instead, pwd displays /home/u/jobs/bin,
> which causes their scripts to fail, and negate my advertisement
> that this migration would be transparent.
>
> My only workaround so far is a script, /local/bin/pwd:
> #!/bin/tcsh
>
> echo $cwd
> exit
>
> This give the desired results, but some users will have to
> add the path /local/bin before /bin in their scripts.
> Their jobs are submitted from an in-house job scheduler that
> su's to the user, to execute their script. The /etc/csh.login
> already has that setup, but I dont think that gets sourced
> by "non logged in" jobs.
> I know that in linux, the "mount --bind" would work.
>
> I hope this explains my situation.
> Thanks
>
> Below was my original request.
>
>
> Tru64 5.1B PK4 on an ES40
>
> Hello,
> I could not find the answer in the man pages, so here
> is my question.
> We wish to mount a subdirectory located in an advfs fileset
> as its own mount point.
>
> oak_local#local    47529432     9093988    38369368    20%    /local
> there is a subdirectory called /local/student
>
> We would like to mount /student as its own mount point, even though
> /home/student is already mounted.
>
> Is there is way of doing this?
> Thanks...
>
>
> Bugs
>
> Operating Systems Analyst for unix systems
> Humboldt State Univ.	Information Technology Services
> Arcata, Calif.
>
> email [email protected]
>