Boost.FileSystem, problem with exists()
Hi, I've been using boost.filesystem and have come up on a problem with exists(). Basically on a windows system it will return true if asking whether a file exists on a non-existent share. The problem is at, operations_posix_windows.cpp:327. There should (?) be an additional check against ERROR_BAD_NETPATH as well. The fuzziness of this function is quite disturbing as shown by the following comment in the code return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) The windows docs don't really help that much by not specify exactly what the failures can be though. Personally I think it should always return false on GetAttributes() error to avoid false positives and the expense of the possible false negatives, but we need a list of all possible errors to be sure that this is the right thing to do. Oh and any chance you can put in serialization support for boost::filesystem::path? I've done it locally and the code is trivial but it would be nice to have it out the box. Anyhow, thanks for a great library (filesystem and the rest of boost). cheers martin
At 05:54 PM 12/1/2004, Martin Slater wrote:
Hi,
I've been using boost.filesystem and have come up on a problem with exists(). Basically on a windows system it will return true if asking whether a file exists on a non-existent share. The problem is at, operations_posix_windows.cpp:327. There should (?) be an additional check against ERROR_BAD_NETPATH as well.
Fixed in CVS. A test case was also added to operations_test.cpp
The fuzziness of this function is quite disturbing as shown by the following comment in the code return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330)
Yes, we got caught flatfooted by the exists() special cases. My fault entirely. Since then there has been further discussion, with the conclusion that a second function is needed, tentatively to be named "is_accessible". It would return true only if GetAttributes() does not return an error.
The windows docs don't really help that much by not specify exactly what the failures can be though. Personally I think it should always return false on GetAttributes() error to avoid false positives and the expense of the possible false negatives, but we need a list of all possible errors to be sure that this is the right thing to do.
Yes, that's what is_accessible() would do. Part of the reason for not just diving in and implementing it is your concern that we have considered all possible errors.
Oh and any chance you can put in serialization support for boost::filesystem::path? I've done it locally and the code is trivial but it would be nice to have it out the box.
Would you care to contribute your code? I'd love to add serialization support. But I haven't had a chance to use the serialization library yet, so some suggested code would light a fire under me.
Anyhow, thanks for a great library (filesystem and the rest of boost).
Thanks! The filesystem library's users have constantly been the inspiration for improving it. --Beman
exists(). Basically on a windows system it will return true if asking whether a file exists on a non-existent share. The problem is at, operations_posix_windows.cpp:327. There should (?) be an additional check against ERROR_BAD_NETPATH as well.
Fixed in CVS. A test case was also added to operations_test.cpp
Thanks for that Breman.
The fuzziness of this function is quite disturbing as shown by the following comment in the code return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330)
Yes, we got caught flatfooted by the exists() special cases. My fault entirely.
Since then there has been further discussion, with the conclusion that a second function is needed, tentatively to be named "is_accessible". It would return true only if GetAttributes() does not return an error.
cool
The windows docs don't really help that much by not specify exactly what the failures can be though. Personally I think it should always return false on GetAttributes() error to avoid false positives and the expense of the possible false negatives, but we need a list of all possible errors to be sure that this is the right thing to do.
Yes, that's what is_accessible() would do. Part of the reason for not just diving in and implementing it is your concern that we have considered all possible errors.
cool
Oh and any chance you can put in serialization support for boost::filesystem::path? I've done it locally and the code is trivial but it would be nice to have it out the box.
Would you care to contribute your code? I'd love to add serialization support. But I haven't had a chance to use the serialization library yet, so some suggested code would light a fire under me.
No problem, it couldn't be simpler (a testament to Roberts hard work). All you need to add is // serialization template<class Archive> void serialize(Archive &ar, const unsigned) { ar & m_path; } to fs::path and all is done. I initially made this non-intrusive but it then gets messy as you need to somehow remember the path checker the path was created with for when you recreate it. I've attached modified versions of the 1_32_0 filesystem code that implements this and also adds a test to path_test.cpp and the modified test jam file. I just added the serialize() function to the public interface, it could be in private with a friend boost::serialization::access declaration but this adds an otherwise unneccessary dependancy on boost serialization. The only problem I had with this was getting the test it to link against the serialization library (I don't really know anything about bjam;) as it doesn't support auto linking, to get round this I also added support for autolinking to serialization (modified from the filesystem autolink in your code, I've attached this here as well for completeness, its also in a seperate post about this). thanks again Martin
participants (2)
-
Beman Dawes -
Martin Slater