https://svn.boost.org/trac10/ticket/5592 <p> I've seen a few posts to boost-dev stating that it is wrong to use CP_THREAD_ACP when converting between 'ANSI' and wide filesystem paths. CP_ACP should be used as well. </p> <p> The issue was raised by Yechezkel Mett in <a class="ext-link" href="http://groups.google.com/group/boost-developers-archive/browse_thread/thread/fa5da7ff49db6d70"><span class="icon">​</span>http://groups.google.com/group/boost-developers-archive/browse_thread/thread/fa5da7ff49db6d70</a> but received no response. </p> <p> Two other users also chimed in in the discussion started at <a class="ext-link" href="http://boost.2283326.n4.nabble.com/filesystem-path-does-not-use-global-locale-s-codecvt-facet-bug-or-feature-td3333336.html"><span class="icon">​</span>http://boost.2283326.n4.nabble.com/filesystem-path-does-not-use-global-locale-s-codecvt-facet-bug-or-feature-td3333336.html</a>. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/5592 Trac 1.4.3 Beman Dawes Sun, 15 Jan 2012 13:38:35 GMT https://svn.boost.org/trac10/ticket/5592#comment:1 https://svn.boost.org/trac10/ticket/5592#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> Applied changeset 76500, reverting to CP_ACP. </p> <p> I'm ambivalent about this fix in that we don't have a test case that demonstrates it is correct. My definition of "correct" is that filesystem operational functions resolve paths exactly the same way that standard library file stream constructors/open resolve paths. </p> <p> If someone could submit a test case, it would be much appreciated. </p> <p> --Beman </p> Ticket