This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: lyx has problem with network directory names

Larry Hall writes:

> Enrico Forestieri wrote:
> > David Arnstein writes:
> >> I just tried to use the Cygwin port of lyx. It cannot cope with my
> >> home directory, which appears as //fs-sj1-15/darnstein in Cygwin. This
> >> is a network directory, obviously.
> >>
> >> When lyx starts up, it emits a complaint
> >> 	QSettings: error creating /fs-sj1-15/darnstein/.qt
> >>
> >> When I try to save a lyx document to my home directory, lyx complains
> >> when it presents its file browser dialog box. It says
> >> 	Could not read directory /fs-sj1-15
> >>
> >> It appears that lyx is trying to access the root directory (/). It
> >> does not seem to know how to interpret the Windows syntax "//."
> > 
> > This is because lyx uses the boostfs library with BOOST_POSIX defined,
> > so any path of the form //xxx/yyy is normalized to /xxx/yyy.
> > I understand that //machine/path is a windowism, but I think that it
> > should be allowed on cygwin. Can this be seen a boost bug?
> > 
> Possibly.  But I expect boost folks would argue that using UNC syntax doesn't
> fit with POSIX semantics.  Currently, the code keys off of BOOST_POSIX or
> BOOST_WINDOWS defines to determine the API to use.  Under Cygwin, BOOST_POSIX
> makes the most sense but with that definition comes the restriction of no UNC
> paths.  Obviously, the workaround for now is to just mount the path in Cygwin
> to create a POSIX path to use.  This will make Lyx happy without too much of a
> burden for the user.

As I explained in an another mail, in this case the culprit is qt3
and not boost. I suspected boost because of the following comment
in boost/libs/filesystem/src/path_posix_windows.cpp:

  // POSIX & Windows cases: "", "/", "/foo", "foo", "foo/bar"
  // Windows only cases: "c:", "c:/", "c:foo", "c:/foo",
  //                     "prn:", "//share", "//share/", "//share/foo"

but, even if UNC paths are not taken into account, the leading '/' is
not stripped out. Instead, it is qt3 that strips it and I also posted
a patch allowing UNC paths in qt3. Maybe it can be applied to the cygwin


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]