> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Arve Knudsen > Sent: Wednesday, October 28, 2009 1:25 AM > To: vim_dev > Subject: Re: Vim creates files named "4913", why? > > > Hi Yakov > > On 28 Okt, 07:47, Yakov Lerner <[email protected]> wrote: > > On Wed, Oct 28, 2009 at 00:52, Yakov Lerner <[email protected]> > wrote: > > > PS > > > I learned once that on win32, you *must* write > > > if(sock == -1) and never if(sock < 0). > > > Win32 sockets can be negative. Yes they really can be. > > > msdn specs _open() as returning -1 on error, not "negative > number". > > > > I was wrong. _open can't return negative fd. > > Maybe moving mch_remove() > > after brace 3512 fixed it ? > > Maybe win32 _open() has > > some race where it creates the file but then returns -1 ? > > I was tipped that my antivirus is a possible explanation for this > behaviour, so I am going to look into that first. If that doesn't work > I might try to debug Vim in Visual Studio, if this doesn't present too > much of a challenge, to see for myself what is going on.
Although I have not been able to repro this myself, I have a theory, which is supported empirically by Arve. Consider: 3508 /* Close the file before removing it, on MS-Windows we 3509 * can't delete an open file. */ 3510 close(fd); 3511 mch_remove(IObuff); There's a race condition between lines 3510 and 3511, wherein another process could open a handle to the file and thus prevent the delete from succeeding. One class of software that is known to do this and cause problems is antivirus programs, which want to scan things for viruses as soon as they are created. Another class of software that sometimes causes problems is local search programs, which want to index things as soon as they are created. Such software can do their tasks unobtrusively if they are written carefully and using the mechanisms provided by the operating system, namely oplocks. Unfortunately there are lots of bad virus scanners and indexers out there (lots of bad software in general!). One solution which is very commonly used in Windows programs is to detect when a delete or rename operation fails (can be narrowed to specific error codes -- sharing violation and access denied), and retry a couple times with short delays in between. The idea is to give the interfering process some time to finish whatever work it was doing with the file. I've had to write such code before. I realize it is ugly, but it works well in practice. It works best with small files. How many people out there have tried to delete a large hierarchy of files using "rd /s /q", and had it inexplicably fail to delete a few files? Yet if you repeat the command it will generally succeed. Most likely a virus scanner or search indexer got in the way and is now out of the way. Another solution, which is cleaner but can only be used in cases where you know you want to delete a file immediately after closing its handle, is to set the delete disposition on the file before closing the handle. There are a couple of ways using Windows APIs to do this. One way is to pass FILE_FLAG_DELETE_ON_CLOSE to CreateFile() when opening the handle originally. Another way is to send down a FileDispositionInfo using SetFileInformationByHandle() or equivalent. (Essentially the DeleteFile() API just does the following: open a handle, set delete disposition, and close the handle; if we break apart these steps, we gain finer control.) I suggest a TODO item around more reliable delete/rename on Windows. I can work on it at some point. Craig --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
