[comp.sys.sgi] 3.2 bug from H E double Toothpick

SML108@psuvm.psu.edu (02/21/90)

Warning:  I have just encountered a rather nasty and merciless bug in 3.2.
          I clicked on a folder to open it up under workspace and it simply
          disappeared.  No query, no appearance in the dumpster, just
          vaporized...

          Nice going to whoever included to this option...

          Scott Le Grand

tadguy@cs.odu.edu (Tad Guy) (02/21/90)

In article <90051.150138SML108@psuvm.psu.edu> SML108@psuvm.psu.edu writes:
> Warning:  I have just encountered a rather nasty and merciless bug in 3.2.
>           I clicked on a folder to open it up under workspace and it simply
>           disappeared.  No query, no appearance in the dumpster, just
>           vaporized...

I've a similar problem...

I double click on a folder, a window appears.

For the briefest of moments, the contents of the folder appear, then
the window becomes empty (actually, it looks like the contents scroll
away, yet the scrollbar shows that the whole window is being
displayed).  The ``listing'' version of the window claims no entries.
Weird...

It only happens to some (few) of my folders.  Most work without problems.

Any ideas?
	...tad

betsy@vesuvius.esd.sgi.com (Betsy Zeller) (02/21/90)

I need to hear more about what happened when you clicked on the folder
and it disappeared. Was it a single click, or a double click? ( Just to 
let you know, workspace has been released in-house in heavy use for the
last 16 months, and released to the field for the last 6, where it also
seems to be in heavy use, and no one has ever reported this problem )
I wonder if the following happened. 
        click on the folder, while moving the mouse, and inadvertantly
        drop the folder into another one. ( this may be in combination
        with an inadvertant name change of the folder, so that when
        you did a 'find' command, your folder name did not turn up.)

The above scenario did happen to one user, who justifiably irately
announced that WorkSpace had eaten his folder, but, upon prompting,
found that the folder had been dropped inside another one.

Please try doing a find command on some of the contents of the missing 
folder. I understand how upset you must be, but I reiterate, look in your
tree for the contents of the directory. WorkSpace has been in heavy use
for a long time and there has never been a case of lost data reported.

genetti@photon.tamu.edu (Jon Genetti) (02/21/90)

>I double click on a folder, a window appears.
>
>For the briefest of moments, the contents of the folder appear, then
>the window becomes empty (actually, it looks like the contents scroll
>away, yet the scrollbar shows that the whole window is being
>displayed).  The ``listing'' version of the window claims no entries.
>Weird...
>
>It only happens to some (few) of my folders.  Most work without problems.

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.

jon genetti.

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

betsy@vesuvius.esd.sgi.com (Betsy Zeller) (02/22/90)

>I double click on a folder, a window appears.
>
>For the briefest of moments, the contents of the folder appear, then
>the window becomes empty (actually, it looks like the contents scroll
>away, yet the scrollbar shows that the whole window is being
>displayed).  The ``listing'' version of the window claims no entries.
>Weird...
>
>It only happens to some (few) of my folders.  Most work without problems.

Are these badly behaved directories mounted over NFS from a foreign
machine? There is a bug in 3.2 workspace (fixed in next release) where
files that are mounted from foreign machines, that have some read 
restrictions on them, and that are exported without root privelege,
display the behaviour you describe. Can you let me know more details?

Betsy Zeller
betsy@sgi.com

robert@shangri-la.gatech.edu (Robert Viduya) (02/22/90)

> 
> Warning:  I have just encountered a rather nasty and merciless bug in 3.2.
>           I clicked on a folder to open it up under workspace and it simply
>           disappeared.  No query, no appearance in the dumpster, just
>           vaporized...
> 
>           Nice going to whoever included to this option...
> 

This could be caused by using the workspace on an NFS mounted directory that's
exported from a non-SGI server.  I noticed this problem before, tracked it down
to the fact that the disappearing directory's mode was 0700 and was on an NFS
filesystem.  The workspace uses a daemon process running in the background to
update the directory views and that process runs as root and root can't normally
see into mode 0700 directories on an NFS filesystem.  One exception is that SGI
NFS servers do allow root on client workstations to see into mode 0700 directories.

I called the hotline to report the problem.  They said that the workspace was working
as designed and if you want to see into NFS directories, they have to be something
like mode 0755 (world-readable).  Which means you can't have secure directories and
still be able to use them from the workspace.

When I asked the hotline why root on client workstations can access mode 0700 NFS
directories, they looked through the NFS server code and discovered a bug and said
it would be fixed in the next release.  We'll see.

			robert
---

Robert Viduya					   robert@shangri-la.gatech.edu
Office of Computing Services
Georgia Institute of Technology					 (404) 894-6296
Atlanta, Georgia	30332-0275

karsh@trifolium.esd.sgi.com (Bruce Karsh) (02/22/90)

In article <51272@sgi.sgi.com> betsy@vesuvius.UUCP (Betsy Zeller) writes:
>I wonder if the following happened. 
>        click on the folder, while moving the mouse, and inadvertantly
>        drop the folder into another one. ( this may be in combination
>        with an inadvertant name change of the folder, so that when
>        you did a 'find' command, your folder name did not turn up.)

I don't know what happened in this case either.  Other possibilities besides
the one Betsy suggested are:

	1. The file was NFS mounted and the mount machine went down.
	2. Some other process (perhaps another user) removed or renamed
	   the directory.

If you can give us any more information on this occurence, please let us know.

tadguy@cs.odu.edu (Tad Guy) (02/22/90)

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

betsy@vesuvius.esd.sgi.com (Betsy Zeller) (02/23/90)

Just a few words to clarify workspace behaviour.

	Any problems viewing directories occur only when all three of
	the following conditions are true.

		i) the problem directories are NFS mounted
		ii) the directories are exported without root privelege
		iii) there is no read/execute permission for others
		    on these directories.


	This bug has been addressed for the next release.

If any undesirable directory viewing behaviour has occurred 
when all three of the above conditions were not true, it would be
really helpful for us to hear about it.