"Boost-users" <boost-users-bounces@lists.boost.org> wrote on 11/19/2014 11:51:00 AM:

From: Aaron_Wright@selinc.com To: boost-users@lists.boost.org Date: 11/19/2014 11:51 AM Subject: [Boost-users] [interprocess] Bizarro File Names (Windows) Sent by: "Boost-users" <boost-users-bounces@lists.boost.org>

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.