OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Phantom Deleted Files in NT 4.0 SP4
From: Neil (mckellarPLANET.EON.NET)
Date: Fri Jun 23 2000 - 14:22:27 CDT

Dave Warren wrote:
> I still call it a bug because if I delete a file, I'm probably not kidding
> and really do want it deleted.

It isn't a bug and it *is* the result of a specific design decision.

In Unix, if I have a file open in some program, like vi for instance, and
someone deletes it, the file doesn't mysteriously disappear in vi. The
decision in Unix is not to display the file when doing directory listings
and allow files with the same path and name to be created. This can cause
problems if the program that is still holding the original writes out the
old contents. So the trade-off under Unix is a potential race condition
on the filename.

In NT, the file still shows up in directory listings and you can't make
a new file with the same path and name. The trade-off under NT is that
legitimate access to the file might be blocked until the old file has been
released and deleted. (Typically seen with FTP access to a web space.
The files are cached in IIS, the FTP client deletes the old file and then
can't write the new one.)

These are simply two different approaches to the same problem.

You can simulate the IIS problem under Unix with some web servers. I have
seen a case where a version of Netscape Enterprise server would cache some
files to speed up access times. A page was deleted and then replaced but
the customer continued to see the old file. We very clearly determined
(eventually by using Lynx on the server in question) that Netscape was
serving different content from what was in the "new" file. A restart of
Netscape solved the problem.

You can also get weird side-effects under NFS if a file is cached locally,
but has changed on the server. The problem exists on both platforms.

The real issue is not one of whether the OS handles this issue correctly,
but whether the applications handle refreshing of the cache and file races
in a robust way.

As I said in a private e-mail to Chuck Wood yesterday, this issue under
NT will crop up more frequently when the box is approaching a resource
limit. Typically I've seen this start to become a regular problem when
the box is short on memory or file space. I couldn't tell you why this
might cause the problem to be more severe, but my experience has shown
this to be the case. 

--
Neil McKellar (mckellarplanet.eon.net)