[Boost-bugs] [ boost-Bugs-1164057 ] boost::filesystem::exists has bugs with UNC paths
Bugs item #1164057, was opened at 2005-03-15 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_id=7586 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists has bugs with UNC paths Initial Comment: boost::filesystem::exists(path("//computer")) always fails, even if the computer exists. boost::filesystem::exists(path("//computer/share")) always succeeds, even if the share doesn't exist. The attached patch fixes this by: - always succeeding for //computer (this is better than always failing) - correctly detecting the existance or not of a share. (The problem here was that the code was missing an error code check) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_id=7586 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs
SourceForge.net wrote:
Bugs item #1164057, was opened at 2005-03-15 14:02
[...] Our bug database is in a really sorry state. It was in a similarly sorry state the last time I looked at it. I'll try to assign and sort some of the unassigned bugs. I notice that some developers do respond to the bug reports via comments, but do not update the resolution and do not close the bug. If you want bug admin rights, please ask. We have a number of open tokenizer/pool/threads/any/lexical_cast/rational bugs. What should we do with them?
I'm using GCC 3.4.3 to compile boost 1.32.0. filesystem compiled ok but when I try to run regression tests, I get the following errors: ../../../bin/boost/libs/filesystem/test/fstream_test.test/gcc/debug/fstream_ test.o(.gnu.linkonce.r._ZTCN5boost10filesystem13basic_fstreamIcSt11char_trai tsIcEEE0_Sd+0xc):/u2/build/boost_1_32_0/boost/test/minimal.hpp:78: undefined reference to `std::basic_iostream<char, std::char_traits<char>
::~basic_iostream()' ../../../bin/boost/libs/filesystem/test/fstream_test.test/gcc/debug/fstream_ test.o(.gnu.linkonce.r._ZTCN5boost10filesystem13basic_fstreamIcSt11char_trai tsIcEEE0_Sd+0x10):/u2/build/boost_1_32_0/boost/filesystem/fstream.hpp:131: undefined reference to `std::basic_iostream<char, std::char_traits<char> ::~basic_iostream()'
Other templates in fstream.hpp compile okay except basic_ofstrem. Any help is much appreciated. Thanks, --Suman
Peter Dimov wrote:
We have a number of open tokenizer/pool/threads/any/lexical_cast/rational bugs. What should we do with them?
threads: michael [glassford] and roland [schwarz], maybe it's better to mail them directly! any: vladimir did this reference stuff recently, so...? As to the others: no idea. Stefan
On Wednesday 16 March 2005 02:22, Stefan Slapeta wrote:
Peter Dimov wrote:
We have a number of open tokenizer/pool/threads/any/lexical_cast/rational bugs. What should we do with them?
threads: michael [glassford] and roland [schwarz], maybe it's better to mail them directly!
any: vladimir did this reference stuff recently, so...?
I see only one any bug in the tracker... in any case, I'm somewhat interested in that library so can try to look into bug report about it. Read: feel free to assign those bugs to me. - Volodya
Stefan Slapeta wrote:
Peter Dimov wrote:
We have a number of open tokenizer/pool/threads/any/lexical_cast/rational bugs. What should we do with them?
threads: michael [glassford] and roland [schwarz], maybe it's better to mail them directly!
I'll try to look into them. Mike
"Peter Dimov" <pdimov@mmltd.net> writes:
SourceForge.net wrote:
Bugs item #1164057, was opened at 2005-03-15 14:02
[...]
Our bug database is in a really sorry state. It was in a similarly sorry state the last time I looked at it. I'll try to assign and sort some of the unassigned bugs.
I notice that some developers do respond to the bug reports via comments, but do not update the resolution and do not close the bug. If you want bug admin rights, please ask.
Every time I add a developer to Boost, I try to give the person all possible rights (except global admin privileges)
We have a number of open tokenizer/pool/threads/any/lexical_cast/rational bugs. What should we do with them?
Well, any and lexical_cast are problematic, because the author/maintainer doesn't watch the list or the bug tracker, but IIRC he doesn't want to turn over maintenance responsibility to anyone else. I'm not sure how best to handle that. Most of the remedies I can think of are rather extreme and unpalatable... and so aren't really remedies at all. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
Our bug database is in a really sorry state. It was in a similarly sorry state the last time I looked at it. I'll try to assign and sort some of the unassigned bugs.
I notice that some developers do respond to the bug reports via comments, but do not update the resolution and do not close the bug. If you want bug admin rights, please ask.
If that's required to mark bugs as resolved, I'm asking. Thanks, Mike
Michael Glassford wrote:
Peter Dimov wrote:
Our bug database is in a really sorry state. It was in a similarly sorry state the last time I looked at it. I'll try to assign and sort some of the unassigned bugs.
I notice that some developers do respond to the bug reports via comments, but do not update the resolution and do not close the bug. If you want bug admin rights, please ask.
If that's required to mark bugs as resolved, I'm asking.
Done.
Peter Dimov wrote:
Michael Glassford wrote:
Peter Dimov wrote:
Our bug database is in a really sorry state. It was in a similarly sorry state the last time I looked at it. I'll try to assign and sort some of the unassigned bugs.
I notice that some developers do respond to the bug reports via comments, but do not update the resolution and do not close the bug. If you want bug admin rights, please ask.
If that's required to mark bugs as resolved, I'm asking.
Done.
Thanks. Could you also add "threads" to the category pull-down? Mike
Michael Glassford wrote:
Peter Dimov wrote:
Michael Glassford wrote:
Peter Dimov wrote:
Our bug database is in a really sorry state. It was in a similarly sorry state the last time I looked at it. I'll try to assign and sort some of the unassigned bugs.
I notice that some developers do respond to the bug reports via comments, but do not update the resolution and do not close the bug. If you want bug admin rights, please ask.
If that's required to mark bugs as resolved, I'm asking.
Done.
Thanks. Could you also add "threads" to the category pull-down?
Done.
Hi: 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 .... "SourceForge.net" <noreply@sourceforge.net> wrote in message news:E1DBK7D-0007Kx-TJ@sc8-sf-web2.sourceforge.net...
Bugs item #1164057, was opened at 2005-03-15 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_id=7586
Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists has bugs with UNC paths
Initial Comment: boost::filesystem::exists(path("//computer")) always fails, even if the computer exists. boost::filesystem::exists(path("//computer/share")) always succeeds, even if the share doesn't exist.
The attached patch fixes this by: - always succeeding for //computer (this is better than always failing) - correctly detecting the existance or not of a share. (The problem here was that the code was missing an error code check)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_id=7586
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs _______________________________________________ Unsubscribe & other changes:
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.
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. 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. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20050317195553.03fb6120@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:
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.
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
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. 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)); }
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
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. 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
participants (1)
-
Beman Dawes -
David Abrahams -
Michael Glassford -
Peter Dimov -
Robert Mathews -
SourceForge.net -
Stefan Slapeta -
Suman Cherukuri -
Vladimir Prus