[comp.unix.wizards] inodes

tale@pawl.rpi.edu (David C Lawrence) (03/07/89)

We have a semi-weird situation on situation in our devlopment
directory here which is causing a bit of a problem and I unfortunately
do not know enough about inodes to figure it out (some, but not
enough).  As usual, I am counting on net.help for a solution. :-)

The situation is this: /develop has four subdirectories names
consult1.[1|2|3|4].  consult1.1 and .3 both are fine, but consult1.2
and .4 have a problem with ..: getwd() can't open it, which breaks a
lot of things that normally would happen in a directory tree, from a
simple pwd to trying to compile with -g.  Now, I know why those things
break so please don't explain it.  The problem is what the heck is
wrong with /develop/consult1.[2|4]/..?  The inode number appears
consistent (shares the inum of .) and the number of links are correct.
Additionally, fsck didn't turn up anything; it things the whole system
is just ducky.  

Any ideas?  Thanks in advance for your help.

Dave
--
      tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu

dik@uva.UUCP (Casper H.S. Dik) (03/09/89)

In article <TALE.89Mar7015647@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes:

>The situation is this: /develop has four subdirectories names
>consult1.[1|2|3|4].  consult1.1 and .3 both are fine, but consult1.2
>and .4 have a problem with ..: getwd() can't open it, which breaks a
>lot of things that normally would happen in a directory tree, from a
>simple pwd to trying to compile with -g.  Now, I know why those things
>break so please don't explain it.  The problem is what the heck is
>wrong with /develop/consult1.[2|4]/..?  The inode number appears
>consistent (shares the inum of .) and the number of links are correct.
>Additionally, fsck didn't turn up anything; it things the whole system
>is just ducky.  
>
>Any ideas?  Thanks in advance for your help.

Are your subdirectories consult1.[24] mount points?

If that is the case you have the permissions of the directories
you mounted your filesystems in wrong.

This doesn't show up with fsck, or ls (after mounting).


Fix: umount the offending filesystems and chmod 755 the mount points.


I wonder whether this comes from Berkeley or from ancient times.

This is roughly what can happen (Sun3/SunOS 3.5:)

Script started on Wed Mar  8 20:18:43 1989
# ls -ld /mnt 					# This is wrong ...
drwx------  2 root           24 Sep 15  1986 /mnt
# mount /dev/sd2c /mnt
# ls -ld /mnt 					# ... but looks ok ...
drwxr-xr-x  3 root         1024 Feb  2 19:33 /mnt
# cd mnt
# ls -la					# ... ok here too ..
total 2
drwxr-xr-x  3 root         1024 Feb  2 19:33 .
drwxr-xr-x 19 root         1024 Mar  7 21:35 ..
# su bin					# Become a non-superuser ..
$ ls -la					# ... now where is '..'?
.. not found
total 1
drwxr-xr-x  3 root         1024 Feb  2 19:33 .
$ pwd 						# '..' lost here too?
getwd: can't open ..
$ exit
# cd /
# umount /mnt					# Fix the problem.
# chmod 755 mnt
# mount /dev/sd2c /mnt
# su bin
$ cd /mnt
$ ls -la					# Everything fine now.
total 2
drwxr-xr-x  3 root         1024 Feb  2 19:33 .
drwxr-xr-x 19 root         1024 Mar  7 21:35 ..
$ exit
# umount /mnt
script done on Wed Mar  8 20:22:33 1989

>Dave
>--
>      tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu


--cd

Casper H.S. Dik
University of Amsterdam     |		      dik@uva.uucp
The Netherlands             |                 ...!uunet!mcvax!uva!dik

jhc@att.ATT.COM (Jonathan Hawbrook-Clark) (03/09/89)

In article <TALE.89Mar7015647@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes:
>The situation is this: /develop has four subdirectories names
>consult1.[1|2|3|4].  consult1.1 and .3 both are fine, but consult1.2
>and .4 have a problem with ..: getwd() can't open it, which breaks ...

You didn't bother to mention which OS this is, but for an AT&T file system
I would bet that you've got a clobbered directory; try this:

	od -c /develop/consult1.[24]

If you see that the first few lines are either all nulls or just
yucky, specifically that there are no entries for '.' or '..', then
there is your problem. The fix is to move everything you can out of the
directory, 'rm -fr' what's left, then move it back in again.

We had a similar problem; Bourne shell gave the results you describe, but
Korn shell worked perfectly: ksh tracks the current directory and 'pwd'
is a built-in. sh uses /bin/pwd which uses getcwd(2), which runs up
the parent directories until it loops, which is root (usually). When
it can't find a '..' then it says something like 'Cannot stat ..!' and
dies. Took us quite some time to track this one down.
-- 
Jonathan Clark		jonathan@mtune.att.com, attmail!jonathan
Any affiliation is given for identification purposes only.

The Englishman never enjoys himself except for some noble purpose.

ric@Apple.COM (Ric Urrutia) (03/16/89)

In article <TALE.89Mar7015647@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes:
>We have a semi-weird situation on situation in our devlopment
>directory here 
>...
>...
>The situation is this: /develop has four subdirectories names
>consult1.[1|2|3|4].  consult1.1 and .3 both are fine, but consult1.2
>and .4 have a problem with ..: getwd() can't open it, which breaks a
>lot of things that normally would happen in a directory tree, from a
>simple pwd to trying to compile with -g.  Now, I know why those things
>break so please don't explain it.  The problem is what the heck is
>wrong with /develop/consult1.[2|4]/..?  The inode number appears
>consistent (shares the inum of .) and the number of links are correct.
>Additionally, fsck didn't turn up anything; it things the whole system
>is just ducky.  
>


You say that /develop/consult1.2/.. shares the same inum as .  This is
your problem.  The .. directory should be linked to the parent directory
(/develop) and the . directory should be linked to /develop/consult1.2.
your best bet is to copy all the files in these directories to a new 
directory, remove consult1.[24], and rename the new directories.
wo

tale@pawl.rpi.edu (David C Lawrence) (03/16/89)

Thanks to the people who tried to provide answers to my problem; one
was correct.  I realize I made it slightly harder by not describing
things a little more accurately -- it was under SunOS 4.0 and each of
/develop/consult1.[1234] was it's own mount point.  The problem was
that consult1.2 was permitted 4700 or something before the mount and
this was not apparent when it was mounted.  We unmounted, chmoded to
755 and remounted.  Everything was fine.

Dave
--
      tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu

shirono@hcx3.SSD.HARRIS.COM (03/17/89)

In comp.unix.wizards, ric@Apple.COM writes:
> In article <TALE.89Mar7015647@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes:
> >We have a semi-weird situation on situation in our devlopment
> >directory here 
> >...
> >...
> >The situation is this: /develop has four subdirectories names
> >consult1.[1|2|3|4].  consult1.1 and .3 both are fine, but consult1.2
> >and .4 have a problem with ..: getwd() can't open it, which breaks a
> >lot of things that normally would happen in a directory tree, from a
> >simple pwd to trying to compile with -g.  Now, I know why those things
> >break so please don't explain it.  The problem is what the heck is
> >wrong with /develop/consult1.[2|4]/..?  The inode number appears
> >consistent (shares the inum of .) and the number of links are correct.
> >Additionally, fsck didn't turn up anything; it things the whole system
> >is just ducky.  
>
> You say that /develop/consult1.2/.. shares the same inum as .  This is
> your problem.  The .. directory should be linked to the parent directory
> (/develop) and the . directory should be linked to /develop/consult1.2.
> your best bet is to copy all the files in these directories to a new 
> directory, remove consult1.[24], and rename the new directories.

Not necessarily.  If /develop/consult1.[24] are mount points, then
/develop/consult1.[24]/. and /develop/consult1.[24]/.. WILL have the same
inum; namely 2.

As for getwd() not being able to open .., well, I don't know.  The only
thing I can think of is wrong permissions in the /develop
/develop/consult1.[24]/.., or the mounted and mounted-on directories.

SUGGESTION: umount /develop/consult1.2, and check its permissions.

--Roberto
______________________________________________________________________________
                               ||   Internet: shirono@ssd.harris.com
     Roberto Shironoshita      ||
      Harris Corporation       ||             ...!novavax---\
   Computer Systems Division   ||   UUCP:     ...!uunet-------!hcx1!shirono
                               ||             ...!mit-eddie-/
------------------------------------------------------------------------------
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Corporation.

merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) (04/12/89)

In article <4822@macom1.UUCP>, rikki@macom1 (R. L. Welsh) writes:
| From article <24110@beta.lanl.gov>, by dxxb@beta.lanl.gov (David W. Barts):
| > 
| > How many files can there be in a single UNIX directory
| ...
| 
| You will undoubtedly run out of inodes before you reach any theoretical
| limit.  Every new file you create will use up one inode.

Not quite.  Try 'ln a b >a'.  Only uses one inode, but two directory
slots.  Do that enough (pragmatically determined :-) times, and you
can (theoretically) run out of directory (or disk) room before running
out of inodes.

Just a lurking guru,
(okay, did I blow it this time too..? :-)
-- 
/=====Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095========\
{        on contract to BiiN (for now :-) Hillsboro, Oregon, USA.             }
{<@intel-iwarp.arpa:merlyn@intelob.intel.com> ...!uunet!tektronix!biin!merlyn }
\=====Cute quote: "Welcome to Oregon... home of the California Raisins!"======/