rn strange ??

Privileged Account root at kunivv1.sci.kun.nl
Tue Jun 12 03:40:35 AEST 1990


In article <1530 at viewlog.UUCP> tom at viewlog.UUCP (Thomas Yen) writes:
>
>	One of my user when he try to run rn and he got:
>
>viewlog:/u/tokamak/przemek>/usenet/bin/rn
>getwd: cannot open ..
>
>Caught an internal error--.newsrc restored
>viewlog:/u/tokamak/przemek>
>
>	Others people include myself work fine. So what is this mean?
>	And what is the "getwd" mean also??

Getwd(3) is the C library routine that tries to work out what the
current directory is called.  It does this by inspecting all the
entries in the parent directory ("..") until it finds a link to the
current directory, and then figuring out the name of the parent
directory in the same way, all the way back to the root directory.
This obviously fails if Mr. Przemek has no read access to one of the
directories involved.  The above suggests that you should check the
protection codes for /u and /u/tokamak, and the rest of your article
suggest that you should also look at /usr, /usr/export and
/usr/export/home.

Maybe it is useful to point out that it takes *execute* permission
for all directories in an absolute pathname to cd into it, and *read*
permission for all except the last to successfully do a getwd(3) once
you are there.

There is one complication: mount points.

When kernel's file name resolution routine is asked about the .. entry
of the root directory of a mounted file system, then it peeks in the
directory on top of which that file system was mounted and returns the
.. entry in this otherwise invisible directory.  Unfortunately, most
versions of Un*x give out this information only to people who have
execute access to the invisible directory.  So, if any of the directories
mentioned in the last paragraph are mount points, you should also unmount
them and look again.

By the way, rn is not the only program suffering from this problem.
Presumably, poor Mr. Przemek cannot run /bin/pwd, since all that does
is print the output of getwd(3).  Simply saying pwd might work: some
shells have a built-in pwd that prints the value of $cwd if it happens
to be correct.  The C-shell also tries to do getwd(3) when it starts
up, and some versions die silently when that doesn't succeed.

Hope this helps,

Hans Mulder	hansm at cs.kun.nl



More information about the Comp.unix.wizards mailing list