Re: [boost] FileSystem Library: Why aren't wide-character names supported? (R evisited)

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 
could
 >not figure out the whether the current rationale, design and 
implementation
 >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 
level
 >of functionality to be supported by FileSystem library.
 >
 >The current implementation for Win32 doesn't seem to support it. The
 >problem
 >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) 
names
 >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?

--Beman