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 bb1_at_humboldt.edu
---------- Forwarded message ----------
From: "Dr Thomas.Blinn_at_HP.com" <tpb_at_doctor.zk3.dec.com>
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_at_ -> /home/bhome1/
> lrwxrwxrwx 1 root system 12 Oct 28 2004 ohome1_at_ -> /home/ohome1/
> lrwxrwxrwx 1 root system 10 Oct 28 2004 tech_at_ -> /home/tech/
> lrwxrwxrwx 1 root system 7 Oct 28 2004 u_at_ -> /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 bb1_at_humboldt.edu
>
Received on Wed Jun 08 2005 - 15:59:22 NZST