Opened 18 years ago

Closed 17 years ago

#297 closed Bugs (Fixed)

boost::filesystem::exists is broken on cygwin

Reported by: libcw Owned by: beman_dawes
Milestone: Component: None
Version: None Severity:
Keywords: Cc:

Description

Compile the following code snippet:

#include <iostream>
#include <boost/filesystem/path.hpp>
#include <boost/filesystem/operations.hpp>

int main()
{
  boost::filesystem::path p = "/usr";
  if (!boost::filesystem::exists(p))
    std::cerr << p.string() << " doesn't exist
according to boost::filesystem" << std::endl;
}


$ uname -a
CYGWIN_NT-5.0 vmware 1.5.10(0.116/4/2) 2004-05-25 22:07
i686 unknown unknown Cygwin

$ g++ -g -I"/usr/src/install/3.3.1/include/boost-1_31"
test.cc -L"/usr/src/install/3.3.1/lib"
-lboost_filesystem-gcc-d-1_31
$ ./a.exe
/usr doesn't exist according to boost::filesystem


Needless to say that /usr does exist:

$ ls -ld /usr
drwxrwxrwx+  18 carlo    Gebruike     4096 Aug  8 14:49
/usr



Change History (4)

comment:1 by david_abrahams, 18 years ago

Logged In: YES 
user_id=52572

Did you build your library with a cygwin-built bjam?  If you 
build your library with a bjam built for Windows, you get 
windows behavior, even under cygwin (so look for something 
like "c:/cygwin/usr").  I'm not sure that Cygwin builds of the 
filesystem library actually use the POSIX interface, but they 
should.

comment:2 by libcw, 18 years ago

Logged In: YES 
user_id=780

Yes bjam was build with cygwin, as follows:

tar xzf boost-jam-3.1.10.tgz
cd boost-jam-3.1.10
./build.sh
cp bin.cygwinx86/bjam.exe "$INSTALL_PREFIX/bin"

And that is done with the following environment (in case
that matters)
TOOLS=gcc
PYTHON_ROOT=/usr
PYTHON_VERSION=2.3
GXX="$CXX"
GCC="$CC"
BOOST_SITE_CONFIG=/usr/src/boost/boost/boost/config/user.hpp

export TOOLS PYTHON_ROOT PYTHON_VERSION GXX GCC
BOOST_SITE_CONFIG

Other, more general environment variables are set too (like
CC, CXX and INSTALL_PREFIX).

I don't entirely understand your remark however, because the
boost code explicitely contains this code:

# if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX )
#   if defined(_WIN32) || defined(__WIN32__) ||
defined(WIN32) || defined(__CYGWIN__)
#     define BOOST_WINDOWS
#   else
#     define BOOST_POSIX
#   endif
# endif

at several place in the code, setting BOOST_WINDOWS
explicitely for __CYGWIN__.

comment:3 by beman_dawes, 17 years ago

Logged In: YES 
user_id=51042

I've finally tracked this down. It is a bug in the
Boost.Filesystem code.

To get the desired cygwin behavior, two things are required.
The cygwin supplied POSIX API has to be used, and slash
(rather than back-slash) has to be given as the root
directory. IOW, cygwin gives different meanings to root
paths depending on the initial character. Since the Boost
code converts slashes to back-slashes, the cygwin libraries
never see the slash.

The problem has now been fixed in the i18n branch code that
will be the basis for 1.34.0. Fixing it in the pre-i18n code
from 1.33.1 is difficult because the changes would need to
be spread between the class declaration in the header and
the implementation in the library. That is a recipe for
disaster since a crash would result if user code defined the
controlling macro one way but the library was built with it
defined the other way. So I won't make any change to the
1.33.x codebase. The branch code is scheduled to be merged
into the main trunk next week in any case.

--Beman

comment:4 by beman_dawes, 17 years ago

Status: assignedclosed
Note: See TracTickets for help on using tickets.