Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
>At least in some versions of NAV in the past, deleting a file would > not actually delete it immediately, but rather a few milliseconds >later. This is also documented behavior of IIS as well--IIS "hangs onto" the file for some time after it was accessed and, even if you delete it, it may be there for awhile. http://support.microsoft.com/default.aspx?scid=kb;en-us;184956 All the references I see relative that are with IIS4 (which I'm stuck with because my server is still NT4), so possibly this was fixed in later releases. Regardless, it demonstrates the behavior is not necessarily only NAV. Glen Starrett -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf Of Ori Berger Sent: Friday, February 28, 2003 7:30 AM To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: [cvsnt] Re: NAV vs. CVSNT BHarriger wrote: > We were recently bit by the NAV/CVSNT incompatibility > (wasn't aware of it until last week) so I'm now trying > to work out the problem with Symantec. At least in some versions of NAV in the past, deleting a file would not actually delete it immediately, but rather a few milliseconds later. Internally, to delete a file on NT, one has to do the following: 1. Open the file with Delete permission 2. Mark the file 'pending deletion' 3. Close the file Upon the last close of the file (it can be open multiple times....), the filesystem is supposed to make the file disappear, but I have not seen any official statement anywhere that ensures that this will be atomic or within a well known time frame. Many file system filters (NAV is one, FUNDELETE from SysInternals is another) delay the actual deletion of the file because they either mark it 'not pending deletion' before close and then do some work before deletion, or otherwise maintain another open handle to the same file. I don't know which API is used in CVSNT, but unlink(), remove() and whatever the Win32 API for this is, all map to the three items above in NT's Native API. The end result is that, although all phases of the deletion are successful, the file is _still_ there for some time (a few milliseconds to a few seconds!) after it was expected to disappear. And this can lead to many subtle bugs. I'm not 100% sure, but I think rename is guaranteed to be atomic (in the sense that a successful return from the rename call indicates that the filename has already changed on the filesystem, rather than that it will be renamed at some point in the future). If this is indeed so, then renaming the file into oblivion before deleting it (e.g., rename it to something like 'random-name-10897.deleteme' before deleting), will solve the conflict. Disclaimer: I solved the CVSNT/NAV conflict by disabling NAV altogether, but I have traced problems in other software in the past to being a result of the files not disappearing immediately when deleted. This is only a speculation. _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs