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.