On Mon, Nov 19, 2001 at 03:04:01PM -0800, John M McIntosh wrote:
> >  > Yes, you can delete an open file on a Unix system. The file is not
> >>  really deleted, but its name is removed from a directory. When
> >>  all open references to the file go away, then the file is really
> >>  deleted. This is analogous to an object which does not get garbage
> >>  collected until all references to the object are gone.
> >
> >And it is common practice to do this when creating temporary files
> >on Unix.  If your application crashes (or is killed), you don't leave
> >breadcrumbs on the floor.
> >
> >-david
> 
> Thank I kinda knew that was the case, since evil things like rm -rf / exist.
> 
> 2nd any windows users (and linux) folks run the tests? Would be nice 
> to know if they did work on those platforms?

It worked fine on Linux with SUnit 3, although I had a (bogus I think)
error running it on SUnit 2. Bottom line is I think it's OK on Linux.

> Bigger question do we want to 'fix' delete to forbid delete if the 
> file is open to preserve how things work in squeak across platform. 
> Or perhaps we close the file if it is open, then delete it. Thoughts 
> anyone?

<opinion>
I think that "fixing" this would amount to trying to hard. This is one
of those cases where things really should work differently on different
platforms. A Squeak application writer would be well advised not to
rely too heavily on the behavior of external "file" objects, because
the concept of a "file" really does mean different things on different
platforms. If you are trying to write a Squeak cross-platform
application which relies on the semantics of "files", then either
you need to be aware of the platform differences, or (more likely)
you should not be using "files" to implement whatever it is that you
are trying to do.
</opinion>

<fact>
You would not be able to "fix" it to forbid delete if the file is
open even if you wanted to. At least it would be very difficult.
On unix, this might amount to implementing an atomic operation that
would check the file system for hard links to the file inode, check
all mounted file systems for symbolic links to the file, check all
references from NFS remote-mounted file systems to the file, and
check for any open file handles from any process owned by any user
on the system. If no such references exist, then unlink the file
to remove its name from the file system, at which time it becomes
"deleted". If references do exist, then fail with a hopelessly
incomprehensible error message.
</fact>

> The purpose of doing these primitive test suites is to catch platform 
> dependent behavior, then the questions is how to fix, or if we should 
> fix to preserve the same behavior across systems.

Well done. I think that this test suite has identified a platform-dependent
behavior that folks would want to be aware of.

Dave