Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-22 08:58:18

At 05:21 AM 9/22/2002, Misha Bergal wrote:

>After reading the "FileSystem FAQ" and the final review discussion I
>not figure out the whether the current rationale, design and
>of FileSystem library support the scenario below?
>Win32 C++ application accepts directory path as user input and counts the
>number of files and subdirectories in it. It seems to be a reasonable
>of functionality to be supported by FileSystem library.
>The current implementation for Win32 doesn't seem to support it. The
>is that in NTFS files and directory names can (and often do) have Unicode
>names. So the conversion from Unicode name of the directory to
>filesystem::path will screw up some of the characters in directory name.
>Consequently, when FileSystem library would try to iterate thru the
>directory because Win32 API would not able to find it.
>I believe that Win32 is not the only platform which allows for Unicode
>names. The implementation for Win32 can be made to return 8.3 (short)
>in case of Unicode name, but I am not sure that it is possible on other
>platforms which allow for Unicode names.

Very good question!

The Filesystem Library has to function in the context of the rest of the C
and C++ Standard Library I/O facilities, so one way to answer your question
is to ask another:

Is it possible to open (and then read) such a file using std::fopen()?

If the answer in yes, then the Filesystem Library should be able to traffic
in those file names too, using the same mechanisms (8.3 names or whatever).
This rationale will be particularly important for operating systems which
allow MBCS names.

If the answer is no, then such a file is not accessible from the Standard
Library, and so it questionable whether or not it should be visible to the
Filesystem Library. (Some cases might best be handled by making them
visible, but the specific cases need to be analyzed and discussed.)

At the very least the Filesystem Library needs Windows test cases added to
make sure the implementation is working appropriately. What is needed
is Win32 API code which creates some directories and files with names
likely to cause trouble, some <cstdio> fopen() based code that accesses
them, and then boost::filesystem::directory_iterator code which looks for
the names.

Would any Win32 experts care to volunteer such code?


Boost list run by bdawes at, gregod at, cpdaniel at, john at