RE: [boost] [ boost-Bugs-1164057 ]boost::filesystem::exists has b ugs with UNC paths
----Original Message---- From: Robert Mathews [mailto:rmathews@envoyww.com] Sent: 17 March 2005 14:56 To: boost@lists.boost.org Subject: [boost] Re: [Boost-bugs] [ boost-Bugs-1164057 ]boost::filesystem::exists has bugs with UNC paths
Initial Comment: boost::filesystem::exists(path("//computer")) always fails, even if the computer exists.
I shall call this, Issue A.
boost::filesystem::exists(path("//computer/share")) always succeeds, even if the share doesn't exist.
... and this Issue B.
Can anyone actually comment on when or if this bug might actually get fixed? It's an obvious bug, the fix is a trivial amount of work - it comes with a patch that I've tested on Win32 ....
Well, as I have indicated above, there are two separate and distinct issues. Issue B does seem like a bug to me. On the other hand, does your fix change it so that //computer/printer is reported as a filesystem? That would be a step backwards. Issue A seems correct behaviour to me. A server is *not* a filesystem - it is a place that filesystems can be found. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
"Martin Bonner" <martin.bonner@pitechnology.com> wrote in message news:E562FCEE3A42D61192880002A5FB433302D7A985@kite.pigroup.co.uk...
----Original Message---- From: Robert Mathews [mailto:rmathews@envoyww.com] Sent: 17 March 2005 14:56 To: boost@lists.boost.org Subject: [boost] Re: [Boost-bugs] [ boost-Bugs-1164057 ]boost::filesystem::exists has bugs with UNC paths
Initial Comment: boost::filesystem::exists(path("//computer")) always fails, even if the computer exists.
I shall call this, Issue A.
boost::filesystem::exists(path("//computer/share")) always succeeds, even if the share doesn't exist.
... and this Issue B.
Can anyone actually comment on when or if this bug might actually get fixed? It's an obvious bug, the fix is a trivial amount of work - it comes with a patch that I've tested on Win32 ....
Well, as I have indicated above, there are two separate and distinct issues.
Thanks for taking a look.
Issue B does seem like a bug to me. On the other hand, does your fix
change
it so that //computer/printer is reported as a filesystem? That would be a step backwards.
Good thought. I tried that - it doesn't report "//computer/printer" as a filesystem.
Issue A seems correct behaviour to me. A server is *not* a filesystem -
it
is a place that filesystems can be found.
Fair enough. So, you are saying that "//server" isn't really a valid path, the minimal valid path is "//server/share"? In that case, I've got a problem with the way the path::iterator works with UNC paths, because given a path like "//server/share/....", it returns "//server" as the first part of the path, and that's not a valid path. Shouldn't the iterator only return valid path parts? So, either, we've got to consider "//server" a valid path, or change the iterator so that it only returns valid paths. I tend to think that fixing the iterator would be a better choice. Rob.
-- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434 _______________________________________________ Unsubscribe & other changes:
participants (2)
-
Martin Bonner -
Robert Mathews