At 04:42 AM 7/20/2005, Jan Hermelink wrote:
This is not (yet) a review, but I use your filesystem library in several unicode projects and am very interested in the wide char implementation. I have tried wpath and wpath_directory_iterator with two projects and run in several minor problems:
- Building I can't build the DLLs on my system (Windows XP SP2, VC 7.1): path.cpp(51) : error C2491: 'boost::filesystem::wpath_traits::imbue' : definition of dllimport function not allowed
Static builds run fine.
This should be fixed soon. Thanks for the report.
- fstream.hpp: Declaration of function narrow_path(const std::wstring & file_ph, ...) If several filesystem fstream objects are declared in different translation units, the linker complains this symbol as multiple defined.
Adding an inline specifier helps as workaround.
- fstream.hpp: Implementation of function narrow_path(const std::wstring & file_ph, ...) This function doesn't work at all on my system, it returns always the empty string. Why is this 8.3 conversion needed,
It is a hack. To avoid having to modify the standard library (which doesn't support wide-character filenames), the 8.3 names are used instead. These appear to always be narrow even if the full name is wide.
can this work on NTFS reliable?
Apparently not. I wasn't aware you could turn them off.
Replacing the current implementation thru a simple narrow conversion helps as workaround.
My understanding (which could be faulty) is that there is no general way to do such a wide to narrow conversion that always works. I'd love to be proven wrong.
- is_symlink() Why isn't this function implemented on Windows? A NTFS junction is symlink, isn't it?
So I've been told. I tried a couple of times to figure out how to use junctions, but my eyes glazed over long before understanding occurred.
After fixing the above problems the library seems to run fine.
Thank you for your work!
And thank you for your comments! --Beman