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

From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-03-21 10:53:24

"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:6.0.3.0.2.20050317195553.03fb6120_at_mailhost.esva.net...
> At 09:56 AM 3/17/2005, Robert Mathews wrote:
>  >Hi:
>  >
>  >Can anyone actually comment on when or if this bug might actually get
>  >fixed?
>
> 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.

>
>  >It's an obvious bug, the fix is a trivial amount of work - it comes with
> a
>  >patch that I've tested on Win32 ....
>
> The patch as submitted is only part of the battle. Another task is to work
> out the need regression test changes to detect the problem. That has to be
> 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));
  }

>
> I've then also got to hand merge the final changes into the i18n version
of
> the code. It has been refactored to such a great extent that automatic
> merges won't work.

>
> Also, thought has to go into the issue of the result if it is an computer
> name only without a share name. See Martin Bonner's posting.

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?

Thanks,
Rob.

>
> --Beman
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>