Path: utzoo!attcan!uunet!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!ukma!xanth!xanth.cs.odu.edu!tadguy
From: tadguy@cs.odu.edu (Tad Guy)
Newsgroups: comp.sys.sgi
Subject: Re: 3.2 bug from H E double Toothpick
Message-ID: <TADGUY.90Feb21202738@osric.cs.odu.edu>
Date: 22 Feb 90 01:27:38 GMT
References: <4292@helios.TAMU.EDU>
Sender: news@cs.odu.edu
Organization: Old Dominion University, Norfolk, VA
Lines: 31
In-reply-to: genetti@photon.tamu.edu's message of 21 Feb 90 09:31:02 GMT

In article <4292@helios.TAMU.EDU> genetti@photon.tamu.edu (Jon Genetti) writes:
> We had the same problems with some of our folders.  It seems if you have
> the world does not have read access to a folder, then the workspace
> is not able to read it.  Open a folder that the contents disappear
> and then change the protection on that directory from a shell and
> the files in that directory will appear in that window.

This is exactly what I discovered today.  In a letter in response to a
correct answer via email from SGI:

| This was the correct answer, thanks.
| 
| I don't know if I mentioned it in my posting, but the machine is
| someone else's, so I don't often get a chance to experiment with it.
| However, today the machine's owner was away and at the same time a
| person from the local SGI office was around, so we looked at the
| problem and on a whim I tried changing the directory permissions and
| the files quickly returned to the window.  He's reported it back to
| the office...
| 
| Thanks again...

> p.s. folks at sgi - is this a bug or a feature?

I consider it a bug, or at least an unfortunate design decision -- the
problem (as gleaned from another posting) appears to be that the
directory reading process is uid 0 (instead of having my permissions),
which isn't trusted over NFS...  The work around of making my
directories world readbable clearly isn't the right solution... :-)

	...tad