Re: [boost] [interprocess] SHARING_VIOLATION due to antivirus

19 Aug 2009

      I made a quick patch to create_file in win32_api.hpp (the patch is 
rather verbose, to make its workings obvious):

static inline void *create_file(const char *name, unsigned long access, 
unsigned long creation_flags, unsigned long attributes = 0)
{
     int tries = 0;
     for (;;)
     {
         void * const res = CreateFileA(name, access, file_share_read | 
file_share_write | file_share_delete, 0, creation_flags, attributes, 0);
         if (tries > 100)
         {
             //ran out of attempts, return and let the exceptions fly
             return res;
         }
         if (res != invalid_handle_value)
         {
             //all went well, return
             return res;
         }
         else if (GetLastError() != 32)
         {
             //we got some other error than an ERROR_SHARING_VIOLATION,
             //let the caller handle the error.
             return res;
         }

         Sleep(1);
         ++tries;
     }
}

With this added my program works fine. I'm not sure whether this sort of 
stuff is needed in any of the other functions in win32_api.hpp.

Cheers
Lars

Lars Hagstrom wrote:
...
Hi,
I've discovered that there is some unfortunate interaction of 
boost::interprocess and at least one antivirus product (ESET Nod32). The 
problem manifests on some installations, and the symptom is that an 
interprocess_exception with a native error code of 32 
(ERROR_SHARING_VIOLATION) occurs when a named_semaphore (or other named 
objects) are opened (well, I've only seen it when opening, but depending 
on the AV product I guess it may happen when creating as well).
Googling a bit on this I found http://support.microsoft.com/kb/316609, 
which suggests that AV products take exclusive locks on files just as a 
file is being opened, which sometimes upsets calls to CreateFile. What 
they suggest is doing retries when a sharing violation occurs.
I'm not really saying that this is a boost.interprocess bug, but at 
least for me it would be handy if it was a little bit more tolerant 
towards AV products.
I've managed (after quite a lot of hard work) to get a test environment 
where I can reproduce this quite easily, so I'm more than willing to 
help out with testing.
Cheers
Lars