Re: [boost] Re: Re: [Boost-bugs] [ boost-Bugs-1164057]boost::filesystem::exists has bugs with UNC paths

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-03-21 18:11:00

At 10:53 AM 3/21/2005, Robert Mathews wrote:
 >
 >> I'll try to get to it this weekend. But there are other patches back 
up,
 >> plus the issues mentioned below.
 >
 >Thank you very much.

I'm still pounding away at documentation for the I18N revisions. Hopefully 
that will be finished tomorrow, and I can get back to the issues raised 
recently.

 >> done first, before the fixes are applied, so that the regression test
 >> changes can be tested.
 >
 >How does that work? Does somebody need to update the list of boost tests,
 >like the ones in operations_test.cpp? I don't see any testing of UNC 
paths
 >in there.
 >
 >Would this do it?
 >
 >  // Test for bug 1164057, shares always detected as existing even when
 >they
 >don't
 >  if ( platform == "Windows" )
 >  {
 >   // Make sure that a share that doesn't exist, doesn't exist
 >   fs::path aInvalidShare( "//share/foo", fs::native );
 >   BOOST_TEST(!fs::exists(aInvalidShare));
 >
 >   // Note: This assumes that the administrative share on this computer 
is
 >available.
 >   fs::path aValidShare( 
string("//")+getenv("COMPUTERNAME")+string("/c$"),
 >fs::native );
 >   BOOST_TEST(fs::exists(aValidShare));
 >  }

That's the idea. It might be better to write a separate test program, 
however, so that incorrect assumptions about what shares are available 
don't cause the whole operations test to fail.

 >Yes, Martin Bonner's posting makes the point that perhaps a computer name
 >only w/o a share isn't a valid path. I tend to agree with him - however,
 >that raised the question that if a computer name w/o a share isn't a 
valid
 >path, then why is the path::iterator returning the computer name w/o a
 >share
 >in the first place?
 >
 >One thought would be that when iterating over the parts of a UNC path, it
 >might be nice if "//computername/share" was returned as one part (the 1st
 >part). Another thought would be if there was some way for the part to
 >indicate that this part was a computername, not a path part ... maybe 
there
 >has already been a long discussion of this?

No, there hasn't been a lot of discussion about UNC issues. That's why they 
aren't handled as well as local paths. Thus cases such as you and Martin 
brought up are very helpful. Please don't take slow response on my part as 
a lack of interest. I'd very much like to improved UNC handling and 
testing, so thank you for bringing up the issue.

--Beman