id summary reporter owner description type status milestone component version severity resolution keywords cc 6065 Accessing Windows paths with non-ANSI characters fails with g++ alf.p.steinbach@… Beman Dawes "For example, the tut5 example in Boost.Filesystem's tutorial does not work with g++ 4.4.1 (it fails to create the filenames with smileys), but that example does work with Visual C++ 10.0. ""ANSI"" here refers to the process' ""ANSI codepage"". By default in a US or Western European Windows installation that's codepage 1252, Windows ANSI Western. Cause: Boost.Filesystem uses extensions in the Dinkumware standard library implementation to provide general Unicode access to paths in Windows. g++'s standard library lacks those extension as of version 4.4.1 (and probably up to and including the latest version). Extending the g++ standard library in a similar way as Dinkumware was discussed in June 2011, , but as far as I know nothing more came of that. Boost.Filesystem v2 worked around the g++ implementation by using Windows short filenames and the Windows API-funcion CreateFile for creation of files. One problem is that the user IN PRINCIPLE can turn off generation of short filenames as a marginal optimization. However, Windows uses short filenames in the registry, reportedly MSI (the Microsoft Installer) uses short filenames, etc., so it's a very unlikely scenario. In the unlikely event that a user does turn off short names, then programs using the v2 workaround will fail in the same way as if they didn't have the workaround, i.e. as currently. " Bugs new To Be Determined filesystem Boost 1.47.0 Problem windows, paths, unicode