Re: [boost] Unexpected behaviour of boost::filesystem::equivalent

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-23 13:49:34

At 02:39 AM 11/22/2004, Daniel Krügler wrote:

 >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.

Ugh! That's ugly.

 >Did others also observe this failure

AFAIK, it is a new test case.

 > 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?

Worth experimenting with. I'll try to dust of the test program and give it 
a try.

Thanks,

--Beman