Boost C++ Libraries: Ticket #9016: filesystem::is_directory() returns false for junction

Thu, 24 Jul 2014 22:58:11 GMT

Upvote! Junctions are by definition directories on windows.

status, milestone changed; resolution set

Beman Dawes — Fri, 25 Jul 2014 19:57:21 GMT

status new → closed
resolution → fixed
milestone To Be Determined → Boost 1.57.0

The real question is whether or not it is safe to treat a Windows ReparseTag of either IO_REPARSE_TAG_SYMLINK or IO_REPARSE_TAG_MOUNT_POINT as a symlink for purposes of Boost.Filesystem. IO_REPARSE_TAG_MOUNT_POINT is the tag assigned by mklink /j to indicate a directory junction.

That appears to work OK, but (1) I'm worried about unintended consequences, and (2) it is too late for this change to go into Boost 1.56.0. So it is now in develop, and a 1.56.1 release of Boost.Filesystem will to into master as soon Boost 1.56.0 ships. That will give early adopters a chance to kick the tires and report any problems encountered before 1.57.0 ships.

Thanks,

--Beman

Sat, 26 Dec 2015 05:01:00 GMT

I just upgraded to boost_1_60_0 and was hit by a regression I think is related to 9016. My windows tests are failing sporadically with the error:

boost::filesystem::read_symlink: The process cannot access the file because it is being used by another process: "r:/data"

Debugging this comparing 1_60_0 to the earlier 1_56_0 I finally narrowed the difference to operations.cpp: bool is_reparse_point_a_symlink, which returns true in 1_60_0 but false in 1_56_0. The return value triggers canonical to call detail::read_symlink, which in turn ends up calling ::CreateFileW with dwShareMode set to 0 so that the file/directory is locked and cannot be opened by another process.

I am running my tests on LSF and many many processes end up accessing the same file / directory at the same time, thus leading the the above error message.

This problem unfortunately is a huge problem for the code I am working on, so I am wondering if I can get the 1_56_0 behavior by reverting the changes to is_reparse_point_a symlink?

martin.apel@… — Fri, 04 Aug 2017 14:59:37 GMT

The implementation as of 1.64 (which is the same as for 1.60) still has a bug related to handling reparse points:

For an input path, which points to a IO_REPARSE_TAG_MOUNT_POINT, it returns something like

E:/?\Volume{3bb57579-710b-11e7-ac12-e8b1fc0f674c}\ \test

which is not accepted by other filesystem function, e.g. by create_directories.

From my point of view it is wrong to treat mount points as symlinks in all cases.