Boost logo

Boost :

From: Daniel Krügler (dsp_at_[hidden])
Date: 2004-11-22 02:39:10


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk