From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-03-17 13:51:44
"Martin Bonner" <martin.bonner_at_[hidden]> wrote in message
> ----Original Message----
> From: Robert Mathews [mailto:rmathews_at_[hidden]]
> Sent: 17 March 2005 14:56
> To: boost_at_[hidden]
> 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
Thanks for taking a look.
> Issue B does seem like a bug to me. On the other hand, does your fix
> it so that //computer/printer is reported as a filesystem? That would be
> step backwards.
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 -
> 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.
> Martin Bonner
> Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ,
> ENGLAND Tel: +44 (0)1223 441434
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk