Re: lyx has problem with network directory names
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. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
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 package? -- Enrico -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
Enrico Forestieri wrote: 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 package? Possibly. That's a determination for the qt maintainer. In the meantime, my suggested workaround should still work. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Enrico Forestieri on 10/8/2006 3:54 PM: 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 Which is wrong, because POSIX allows implementations to treat //share specially, which cygwin does. In other words, //share is not Windows only. Whether or not //share is interpreted as a Windows UNC path or as some other meaning doesn't matter; what matters is that it is wrong for ANY application claiming POSIX compatibility to flatten //share to /share, because POSIX allows these two to be different. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFKZvK84KuGfSFAYARAjN8AKDBB2Y/ANvcHZgw8XaCcEWxV1yuBwCfa4lv MO5iKKncXSd1DkgEMJM5CSE= =MPxF -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
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? -- Enrico -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
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? Yes, it is most definitely a boost bug and should be reported upstream. POSIX allows implementations to treat leading // specially, so boost is violating POSIX by normalizing it. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
On Sat, Oct 07, 2006 at 02:36:46PM +, Eric Blake wrote:
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?
Yes, it is most definitely a boost bug and should be reported
upstream. POSIX allows implementations to treat leading //
specially, so boost is violating POSIX by normalizing it.
Sorry for the noise, but boostfs seems innocent. I investigated
the problem and it turned out that qt3 is to be blamed here.
Indeed, UNC paths are accounted for only when Q_OS_WIN32 is defined.
The attached patch for qt 3.3.5 allows UNC paths on cygwin, too.
--
Enrico
diff -uNr qt3.orig/src/dialogs/qfiledialog.cpp qt3/src/dialogs/qfiledialog.cpp
--- qt3.orig/src/dialogs/qfiledialog.cpp2005-09-30 17:58:32.0
+0200
+++ qt3/src/dialogs/qfiledialog.cpp 2006-10-07 22:54:36.0 +0200
@@ -5732,6 +5732,17 @@
QString p = QDir::convertSeparators(u.path());
if(p.contains(':') == 1)
return TRUE;
+#elif defined(Q_OS_CYGWIN)
+ QString p = u.path();
+ if ( p == / )
+return TRUE;
+ if ( p[0] == '/' p[1] == '/' ) {
+int slashes = p.contains( '/' );
+if ( slashes = 2 )
+return TRUE;
+if ( slashes == 3 p[ (int)p.length() - 1 ] == '/' )
+return TRUE;
+ }
#elif defined(Q_OS_UNIX)
if ( u.path() == / )
return TRUE;
diff -uNr qt3.orig/src/kernel/qurl.cpp qt3/src/kernel/qurl.cpp
--- qt3.orig/src/kernel/qurl.cpp2006-02-16 04:23:44.0 +0100
+++ qt3/src/kernel/qurl.cpp 2006-10-07 22:56:36.0 +0200
@@ -833,7 +833,7 @@
if ( !d-host.isEmpty() d-host[ 0 ] == '@' )
d-host.remove( (uint)0, 1 );
-#if defined(Q_OS_WIN32)
+#if defined(Q_OS_WIN32) || defined (Q_OS_CYGWIN)
// hack for windows file://machine/path syntax
if ( d-protocol == file ) {
if ( url.left( 7 ) == file://
@@ -1027,7 +1027,7 @@
if ( QDir::isRelativePath( d-path ) ) {
d-cleanPath = d-path;
} else if ( isLocalFile() ) {
-#if defined(Q_OS_WIN32)
+#if defined(Q_OS_WIN32) || defined(Q_OS_CYGWIN)
// hack for stuff like \\machine\path and //machine/path on windows
if ( ( d-path.left( 1 ) == / || d-path.left( 1 ) == \\ )
d-path.length() 1 ) {
diff -uNr qt3.orig/src/tools/qdir.cpp qt3/src/tools/qdir.cpp
--- qt3.orig/src/tools/qdir.cpp 2006-02-15 19:26:24.0 +0100
+++ qt3/src/tools/qdir.cpp 2006-10-07 23:00:02.0 +0200
@@ -1293,6 +1293,9 @@
} else {
newPath = name.left(2) + newPath;
}
+#elif defined(Q_OS_CYGWIN)
+ if ( name[0] == '/' name[1] == '/' ) // //machine/x/ ...
+ newPath.insert( 0, '/' );
#endif
}
return newPath;
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
On Wed, 4 Oct 2006, David Arnstein wrote: On Wed, Oct 04, 2006 at 08:19:32PM -0400, Larry Hall (Cygwin) wrote: So mounting the share should work-around this issue, right? Yes. I also have to redefine the HOME environment variable to P:/ and do cd P:/ before starting lyx, in order to get it to work correctly. In this case, P: is the drive that I mounted the share on. I don't believe Larry meant mount in that sense. You can use Cygwin's mount, like this: mkdir -p /mnt/darnstein mount '\\fs-sj1-15\darnstein' /mnt/darnstein and then set your HOME to /mnt/darnstein. Oddly enough, lyx still complained QSettings: error creating P:/.qt I don't know what the problem was. I created P:/.qt as an empty directory using mkdir and all is well, apparently. Anyway, thank you for the suggestion Mr. Hall. FYI, using paths with colons in them will probably cause trouble at some point down the line with some tool or another that treats the colon as the separator for the remote machine name. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
David Arnstein wrote: 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 //. So mounting the share should work-around this issue, right? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lyx has problem with network directory names
On Wed, Oct 04, 2006 at 08:19:32PM -0400, Larry Hall (Cygwin) wrote: So mounting the share should work-around this issue, right? Yes. I also have to redefine the HOME environment variable to P:/ and do cd P:/ before starting lyx, in order to get it to work correctly. In this case, P: is the drive that I mounted the share on. Oddly enough, lyx still complained QSettings: error creating P:/.qt I don't know what the problem was. I created P:/.qt as an empty directory using mkdir and all is well, apparently. Anyway, thank you for the suggestion Mr. Hall. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
