I can confirm that Vim creates these files when my antivirus's realtime filesystem protection is enabled. I've opted to turn it off, since it's such an annoyance :/ For the record, I use ESET NOD32.
Arve On 6 Nov, 03:07, Craig Barkhouse <[email protected]> wrote: > > -----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 -~----------~----~----~----~------~----~------~--~---
