Hello, I enabled filesystem v3 after upgrading to 1.44. The api changes that caused the compiler to signal errors were rather easy to fix. However when running my program, it behaves differently from the way it used to. I narrowed it down to the following: char buf[MAX_PATH]; HRESULT res = ::SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, buf); boost::filesystem::path result(buf); // 'result' is after this "C:\Documents and Settings\rvanhout\Application Data" result /= "MyCompany"; At this point, 'result' *still* contains "C:\Documents and Settings\rvanhout\Application Data" whereas with v2 it used to contain "C:\Documents and Settings\rvanhout\Application Data\MyCompany\MyProduct". (environment: Windows (obviously) with VS 2008 (vc9)) There seem to be two way to get the desired behaviour: - initialize the path with a trailing slash, like this: boost::filesystem::path result(buf + std::string("/")); - convert 'buf' into a std::string first: std::string str(buf); boost::filesystem::path result(str); So I guess my code broke because the path is not initialized with the platform's native path encoding (although std::string is char also and it does work). Is this by design? It seems quite unintuitive to me. Second thing I was bit by is that the io streaming operator now seems to add quotes to a path with spaces in it when streaming a path object to an ostringstream. The string that is returned with .string() isn't quoted, of course, so my 'fix' is to not stream path objects anymore but add the .string() call. What's more important, is there a way to let the compiler signal these situations in my code? The way it is now, everything compiles but I have no way to know if it will actually work as it used to/should. Otherwise, it might be an idea to add #pragma warning statements to those parts for a release or two, to give people a heads up. Thanks. regards, Roel Vanhout