[filestreams] Does native not work correctly in Windows?
The following line in my Windows program: boost::filesystem::path my_path(my_filename, boost::filesystem::native); converts backslashes in my_filename to forward slashes, which means than when I use boost::filesystem::exists on the result, the file is reported as not existing even though it does. I notice the comments in boost::filesystem::m_path_append(), which is called by the constructor of boost::filesystem::path, say that this is what the function does, but this contradicts the documentation. http://boost.org/libs/filesystem/doc/portability_guide.htm says, of native: Side effect: Syntax for path constructor /src/ string is implementation defined according to the path syntax rules for the operating system. Use: In path constructors, when the source is operator input or other sources which are formatted according to operating system rules. I understand this to mean that boost::filesystem::native converts the file into the format required by the OS. I certainly would not expect it to make the format wrong if it is already correct. Is there something I've overlooked here, or is this a bug, or is the documentation wrong (or just misleading)? I'm puzzled. Paul
"Paul Giaccone" <paulg@cinesite.co.uk> wrote in message news:43EC8417.8010000@cinesite.co.uk...
The following line in my Windows program:
boost::filesystem::path my_path(my_filename, boost::filesystem::native);
converts backslashes in my_filename to forward slashes, which means than when I use boost::filesystem::exists on the result, the file is reported as not existing even though it does.
I notice the comments in boost::filesystem::m_path_append(), which is called by the constructor of boost::filesystem::path, say that this is what the function does, but this contradicts the documentation. http://boost.org/libs/filesystem/doc/portability_guide.htm says, of native:
Side effect: Syntax for path constructor /src/ string is implementation defined according to the path syntax rules for the operating system.
Use: In path constructors, when the source is operator input or other sources which are formatted according to operating system rules.
I understand this to mean that boost::filesystem::native converts the file into the format required by the OS. I certainly would not expect it to make the format wrong if it is already correct.
Is there something I've overlooked here, or is this a bug, or is the documentation wrong (or just misleading)? I'm puzzled.
I assume you are using 1.33.1 or earlier. It certainly handles both back and forward slashes correctly for the mostpart, although I wouldn't be surprised if there were obsure bugs in corner cases such as \\? pathnames. Why don't you give the 1.34 version from the CVS HEAD a try. It uses a much simplified (and hopefully improved) way of handling native formats. You no longer have to do anything special such as using a special constructor argument. Good luck, --Beman
Beman Dawes wrote:
"Paul Giaccone" <paulg@cinesite.co.uk> wrote in message news:43EC8417.8010000@cinesite.co.uk...
The following line in my Windows program:
boost::filesystem::path my_path(my_filename, boost::filesystem::native);
converts backslashes in my_filename to forward slashes, which means than when I use boost::filesystem::exists on the result, the file is reported as not existing even though it does.
I notice the comments in boost::filesystem::m_path_append(), which is called by the constructor of boost::filesystem::path, say that this is what the function does, but this contradicts the documentation. http://boost.org/libs/filesystem/doc/portability_guide.htm says, of native:
Side effect: Syntax for path constructor /src/ string is implementation defined according to the path syntax rules for the operating system.
Use: In path constructors, when the source is operator input or other sources which are formatted according to operating system rules.
I understand this to mean that boost::filesystem::native converts the file into the format required by the OS. I certainly would not expect it to make the format wrong if it is already correct.
Is there something I've overlooked here, or is this a bug, or is the documentation wrong (or just misleading)? I'm puzzled.
I assume you are using 1.33.1 or earlier. It certainly handles both back and forward slashes correctly for the mostpart, although I wouldn't be surprised if there were obsure bugs in corner cases such as \\? pathnames.
Why don't you give the 1.34 version from the CVS HEAD a try. It uses a much simplified (and hopefully improved) way of handling native formats. You no longer have to do anything special such as using a special constructor argument.
Good luck,
--Beman
Thanks. I was about to post an example of what I am doing, but, bizarrely, it's all working now. The boost::filesystem::path is initialised from a std::string of the form <drive>:\<dir1>\<dir2>\....\<dirn>/<filename>.<extension> and the backslashes is converted to forward slashes. The .string() function (and the .c_str() function on that) give strings containing forward slashes. ::exists() says the file exists, and the file loads OK. I'm using Windows Visual C++ 7.1.3088 and Boost 1.33.1. I wonder what was wrong before. The problem just seems to have gone away of its own accord. I did not recompile the program or change the input. Still, it's back to the correct behaviour, so I'm not complaining. Thanks for your feedback in any case. Paul
Beman Dawes wrote:
"Paul Giaccone" <paulg@cinesite.co.uk> wrote in message news:43EC8417.8010000@cinesite.co.uk...
The following line in my Windows program:
boost::filesystem::path my_path(my_filename, boost::filesystem::native);
converts backslashes in my_filename to forward slashes, which means than when I use boost::filesystem::exists on the result, the file is reported as not existing even though it does.
I notice the comments in boost::filesystem::m_path_append(), which is called by the constructor of boost::filesystem::path, say that this is what the function does, but this contradicts the documentation. http://boost.org/libs/filesystem/doc/portability_guide.htm says, of native:
Side effect: Syntax for path constructor /src/ string is implementation defined according to the path syntax rules for the operating system.
Use: In path constructors, when the source is operator input or other sources which are formatted according to operating system rules.
I understand this to mean that boost::filesystem::native converts the file into the format required by the OS. I certainly would not expect it to make the format wrong if it is already correct.
Is there something I've overlooked here, or is this a bug, or is the documentation wrong (or just misleading)? I'm puzzled.
I assume you are using 1.33.1 or earlier. It certainly handles both back and forward slashes correctly for the mostpart, although I wouldn't be surprised if there were obsure bugs in corner cases such as \\? pathnames.
Why don't you give the 1.34 version from the CVS HEAD a try. It uses a much simplified (and hopefully improved) way of handling native formats. You no longer have to do anything special such as using a special constructor argument.
Good luck,
--Beman
I spoke too soon. I was looking at the wrong part of the program. I also see what the problem is. In the first case, I call ::exists() on a path, and this works correctly. In the second case, which is failing, I am calling it on the std::string returned by path::string(), and because this contains forward slashes but no indication that the OS is Windows (which, presumably, a "path" object does), the file cannot be found. Thanks for the feedback. Paul
participants (2)
-
Beman Dawes -
Paul Giaccone