Hi booster, its quite a long time ago since I could follow the threads here more thoroughly :-( , so the following information might not be new one. During tests of the current Win32 implementation of boost::filesystem::equivalent I observed that the function unexpectingly fails (my test environment was Win XP SP 1 with MSVC7.1) if it compares a "soft link" created via the DOS command "subst" (or its API analogon ::DefineDosDeviceA/W) with the corresponding mapped path object (Lets say I map M: to the existing directory C:\temp). To get an understanding of the test failure I debugged the implementation and found that actually the first test part (getting the handles and comparing the VSN's + further data) gave the expected positive result, but that the very last step, i.e. the comparison of both st_dev values, gave a final unequality. Did others also observe this failure and don't you think that the expected result should show the identity of the underlying path objects? Of course there might be legitimate arguments for the decision for the current behaviour, but I would like to know about them. I am not an expert to argue about the comments in the source code which say that "In theory, volume serial numbers are sufficient to distinguish between devices, but in practice VSN's are sometimes duplicated, so device id is also checked.[..]" The question now is: Should different (MS DOS) device names pointing to the same underlying (Windows NT) device not be compared equivalent? I could think of the following test extension (at least under Windows, regrettably I am not a posix expert to provide a similar solution): If the VSN' and further data have returned a positive result, but the check of both st_dev values fails, one should try to check whether the underlying devices are actually the same, e.g. using the ::QueryDosDeviceA/W API function. What do you think? Greetings, Daniel Krügler