Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!apple!amdahl!dgcad!gary From: gary@dgcad.SV.DG.COM (Gary Bridgewater) Newsgroups: comp.windows.x Subject: Re: R4 Athena Widget question. Message-ID: <1445@proa.SV.DG.COM> Date: 7 Mar 90 08:52:24 GMT References: <100920180@hpcvlx.cv.hp.com> <9003042232.AA01692@underprize.think.com> Reply-To: gary@proa.SV.DG.COM () Organization: Data General SDD, Sunnyvale, CA Lines: 50 In article <9003042232.AA01692@underprize.think.com> rlk@THINK.COM (Robert L. Krawitz) writes: > > Date: 1 Mar 90 01:35:44 GMT > From: hp-pcd!hpcvlx!ben@hplabs.hp.com (Benjamin Ellsworth) > > Every UN*X system that I've used allows the programmer to create a > file, and then unlink it from the file system. As long as it is not > closed, it exists known only by the program until it exits. (The > Morris worm exploited this behavior.) When the program calls exit(), > the system calls clean everything up very nicely. > >This doesn't work too well on NFS filesystems... Whose? What rev? What fails? Scenario: open local file remove file do stuff with file system crashed data is gone Scenario: remote shell a program that opens a "local" file over "there" etc. Scenario: open file on NFS mounted disk remove file do stuff with file server crashes server comes up continue doing stuff with file exit {data may hang around in funny named file - cron cleans up} Scenario: open file on NFS mounted disk remove file do stuff with file "my" system crashes data is gone The difference with the NFS mounted file is that it gets renamed to a funny name instead of being instantly destroyed. It is gone in the sense that if you or anyone reopens the same original name it will not exist. How is this a problem? It is a bit of an inconvenience but, to our site, very much worth it. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary The impossible we understand right away - the obvious takes a little longer.