Re: [Boost-users] [interprocess] Bizarro File Names (Windows)

Subject: Re: [Boost-users] [interprocess] Bizarro File Names (Windows)
From: Aaron_Wright_at_[hidden]
Date: 2015-01-28 17:55:16

"Boost-users" <boost-users-bounces_at_[hidden]> wrote on 11/19/2014 
11:51:00 AM:

> From: Aaron_Wright_at_[hidden]
> To: boost-users_at_[hidden]
> Date: 11/19/2014 11:51 AM
> Subject: [Boost-users] [interprocess] Bizarro File Names (Windows)
> Sent by: "Boost-users" <boost-users-bounces_at_[hidden]>
> 
> I have a service that is running in Windows Server 2008 R2 SP1 that 
> uses shared memory. It runs fine for a month or so, but then stops 
> working correctly. When I check the C:\ProgramData
> \boost_interprocess\*\ folder, I get a bunch of weird file names, such 
as: 
> 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EBFFFFFF 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000ECFFFFFF 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EDFFFFFF 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EEFFFFFF 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EFFFFFFF 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F0FFFFFF 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F1FFFFFF 
> 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F2FFFFFF 
> 88C861CD6DE2CF014B04F3CC1200D001A40700000AFFFFFF 
> 88C861CD6DE2CF014B04F3CC1200D001A40700000BFFFFFF 
> 88C861CD6DE2CF014B04F3CC1200D001A40700000CFFFFFF 
> 88C861CD6DE2CF014B04F3CC1200D001A40700000DFFFFFF 
> ... 
> (and so on) 
> 
> These are not even close to the names that are supposed to be used. 
> They seem to increment a bit, then shift slightly, and start 
> incrementing again. When I restart the service I get similar named 
> files and patterns, and my services crashes because it can't grow 
> shared memory (presumably because the file names are not correct). I
> have to restart the box in order to get the correct behavior. 
> 
> Has anyone seen this behavior before? 
> 
> ---------------------------------------------------------
> 

Just in case anyone runs into the same problem. I finally figured out what 
was causing this issue.

It was caused by the issue referenced here: 
https://svn.boost.org/trac/boost/ticket/9767

So the bizarro file names mentioned above are caused by one process 
holding open file handles while another process deletes them (because the 
6005 event no long exists). Apparently Windows just shows these NTFS 
identifiers instead of the file names because the files are actually 
deleted. 

It seems there is just no easy way to get a reliable boot time in Windows, 
as the implementation of this has waffled between API calls and Event Log 
trolling and back again. The current code in 1.57 is not perfect yet as it 
can be broken by hibernation and shifts in time, as noted in the comments 
in the code. A work around is to specify the folder yourself at build 
time.