Question

I've been using Boost 1.46.1 in my project until a week ago. After upgrading everything to Boost 1.55.0 I noticed that some functionality is not working as before.

My software loads configuration files which are placed via SymLinks. I'm using Microsofts mklink to do this.

I today found out that while boost::filesystem::is_empty() in version 1.46.1 was returning false for my links, it now returns true in 1.55.0. Unfortunately I'm not able to change the component which uses that code. The result is that my config files aren't loaded anymore.

  • Is there a way to create links in a way that Boost is able to recognize them?
  • If I get access to the code: How would I need to change it to work again?

UPDATE:

Some more information in response to the comments:

  • The SymLink is valid, there is a file linked to it
  • The file linked to the SymLink is not empty, it is a valid config file which worked before
  • The user has permissions to the SymLink and to the linked file
  • I'm able to do an fopen on that file and read its contents

UPDATE2:

I just created a Github project with everything included to recreate the issue. I used VS 2013 Express to compile the program:

Was it helpful?

Solution

The problem is that older versions of Boost filesystem (V2) on Windows used VC++'s stat() function to obtain the information on the target file, and that function followed symlinks.

Newer versions of the filesystem library (V3) use the the Win32 GetFileAttributesExW() API, and it doesn't follow symlinks, so the size of the object specified by the path gets returned as 0.

It looks like filesystem V3 was made the default in Boost 1.46 and V2 was removed from the library in 1.48. One possible fix for your problem is to move back to a version of Boost before 1.48 (and possibly build the libraries with the BOOST_FILESYSTEM_VERSION macro set to 2).

I have opened a bug against this and the bug report includes a patch against libs/filesystem/src/operations.cpp that fixes the problem:

Keep in mind that the patch I submitted in the bug report hasn't had much testing (for example, it needs to be tested against other versions of Windows, with the MinGW toolchain, with paths that include characters outside the ASCII range, directories as targets, and probably a number of other things I haven't thought of). However, if you want to continue using a recent Boost release, you're welcome to patch your local Boost libs to see if it solves the problem for you.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top