Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request
From: pearlman@rand.org (Laura Pearlman)
Newsgroups: comp.sys.sun
Subject: Re: Problems with 'automount' and 'getwd'!
Keywords: Miscellaneous
Message-ID: <6050@brazos.Rice.edu>
Date: 24 Mar 90 03:02:20 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 42
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n87
X-Sun-Spots-Digest: Volume 9, Issue 96, message 6

In article <5959@brazos.Rice.edu> rgm@thorin.hw.stratus.com writes:
>X-Sun-Spots-Digest: Volume 9, Issue 87, message 12
>
>We are having problems with the automount program.  We are running SunOS
>4.0.3 and the problem shows up something like this:
>
>    thorin% pwd
>    pwd: getwd: can't open ..
>
>and:
>
>    thorin% df .
>    Filesystem            kbytes    used   avail capacity  Mounted on
>    Could not find mount point for .
>
>but you can still work in the directory and list it etc.

Getwd and df will fail like that if you mount a directory on top of
itself, and you're not in the top-level mount point directory.  In other
words, if you do:

	mount foo:/bar /mnt
	cd /mnt/blech
	# edit out the "foo:/bar ... /mnt" entry in /etc/mtab
	mount foo:/bar /mnt
	pwd
	df .

then you'll see the same behavior you described above.  This is because
whenever an nfs filesystem is mounted, it's assigned a dev number that is
different from the dev numbers of any other filesystems mounted at the
time.  The problem in the example above is that the dev number for "."
(the first dev number assigned) is now different from from the dev number
for "/mnt/blech" (the second dev number assigned).

I don't have any idea why automount would behave this way, though.  My
only guess is that somehow automount has attempted to unmount a filesystem
and unlinked its symlink without realizing that the unmount failed, and
then remounted the filesystem again later because the symlink was gone.

		-- Laura
		   pearlman@rand.org