Re: Can't read lock file
// Which is bad since FAT32 has no security at all. Any process of any user on the machine can overwrite any file, even in the Windows folder. NTFS is much more secure and has a couple of features you never get with FAT32, and hardlinks are only one minor advantage. You should really update the filesystem to NTFS using the on-board convert.exe tool. Well. I took the advice and converted both FAT32 systems (one for 1.5 and one for 1.7) to NTFS. I quite like some of the file management consequences - e.g. chkdsk output, more efficient use of space - but working within Cygwin I'm not a happy bunny. I am sure that in many parallel universes the step you have advised results in huge benefits, but so far I can only report detriment to [1] use and [2] understanding. (I know [1] that requests/ complaints/ comments should not be too user-specific and as for [2] I'm really just hanging myself out to dry. But here goes ...) I operate both Cygwins 1.5 and 1.7 on a partitioned portable drive hooked up to different machines at different times. After changing to NTFS I find statements of folder permissions completely incomprehensible e.g. the + in drwxrwxrwx+; also that they do not alter after chmod instructions in the way I was expecting; that there are MANY additional user names and group names including ?? ; that files I worked on on Machine 1 now produce Permission denied when I try to work on them on Machine 2 All right, all of the above merely make manifest a complete lack of understanding of permissions, privileges, rights, etc. But it is after all my mobile drive, and every file on it was put there by me, is owned by me in some sense, and I ought to be able to do stuff. Finally (and I have tried to search for a solution) I alias ls as ls --color and had some lovely rxvt* xterm* and gnuplot* color schemes set up in ~/.Xdefaults. Now the rxvt* and xterm* color schemes have been lost (to be replaced by, I assume, some standard set, with a particularly horrid colour combination for directories (fg blue bg green). Confusingly, realised gnuplot* colors are still as set in .Xdefaults. Is there a way I can recover what I want for rxvt and xterm (maybe by putting the instructions into a different file). I think I will revert to FAT32 partitions and maybe put up with a working if not current XWin in 1.7. Like my experience with mobile phones, there is a threshold of sophistication beyond which I am just plain incapable of making progress, and the conversion of FAT32 to NTFS seems to have crossed that threshold for me with its unintended (or unexpected anyway) consequences. It is a marvellous advance in security I am sure (and I am very appreciative that Corinna and Jon took this up and responded to me) but I guess it just isn't for me. Thank you. If meanwhile you can point me somewhere for a solution to the lost colour schemes, I would be very grateful. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file
On 11/11/2009 07:40, Fergus wrote: I have made no alterations/ patches/ amendments and have a completely current [1.7] system. For all of cygwin1.7.61.dll - cygwin1.7.64.dll the command run XWin fails with a reference to /vat/log/XWin.0.log which reads Can't read lock file /tmp/.X0.lock But when reverting to cygwin1.7.60.dll everything goes ahead smoothly and correctly and I can start a X terminal etc. Q1. Is it still the case that this problem is not well understood as in this reference? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file (My experiments with possible cause/ cure are confounded because on Machine 1 I have NTFS filesystems but lack administrator rights and on Machine 2 where I am Administrator, all filesystems are FAT32.) Perhaps this FAQ needs a bit of clarification. Creating the lockfile will fail if /tmp is on a FAT32 filesystem, for the reasons outlined in Corinna's email. (although I guess this may have behaved differently in some 1.7.x beta version if you haven't seen it there) For reasons which I don't currently understand, creating the lockfile also reportedly fails sometimes for people who have /tmp on a NTFS filesystem. If you can contribute some information which might help in solving this problem, please do so at [1] [1] http://sourceware.org/bugzilla/show_bug.cgi?id=9778 Q2. Is there anything obvious in the progression from cygwin1.7.60.dll to cygwin1.7.61.dll that might explain why the start command run XWin works with 1.7.60 and fails with 1.7.61? Finally Q3. Confession: I am completely confused by all recent posts about LANG, locale and all the rest. Are fiddling with LANG or applying patches such as described at http://cygwin.com/ml/cygwin-xfree/2009-11/msg00071.html fixes intended to address problems starting XWin? If you are not setting LANG (or are setting it to C.UTF-8) and have xorg-server-1.7.1-2, you will probably experience random crashes in multiwindow mode) Until there is a new libX11 release, if you are experiencing such crashes, applying that patch in that email OR setting LANG to something more sensible (e.g. en_GB.UTF-8) should resolve that problem. Thank you. Fergus PS Not quite finally. Can I please ask a 4th question: Q4 Why are questions about X specifically directed to a different mailing list? Apart from occasional high-frequency dialogue as at present, posts about X are (or seem to me to be) no more frequent than posts about grep or ls or chmod or ... . The main Cygwin list has a much higher readership and posts directed there might generate many useful hints, tips, experiences, fixes or even solutions? I am lazy and don't read the main list :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file
On 11/11/2009 10:07, Corinna Vinschen wrote: On Nov 11 07:40, Fergus wrote: Q1. Is it still the case that this problem is not well understood as in this reference? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file Hardlinks don't work on FAT filesystems since FAT doesn't support them. Up to Cygwin 1.7.0-60, hardlinks on FAT were faked by copying the file. This has obvious downsides (unsecure, potential denial-of-service problems, portability), so we discussed and decided to remove this fake and to return an error instead when trying to create a hardlink on a FAT FS: http://cygwin.com/ml/cygwin/2009-09/msg00208.html (My experiments with possible cause/ cure are confounded because on Machine 1 I have NTFS filesystems but lack administrator rights and on Machine 2 where I am Administrator, all filesystems are FAT32.) Which is bad since FAT32 has no security at all. Any process of any user on the machine can overwrite any file, even in the Windows folder. NTFS is much more secure and has a couple of features you never get with FAT32, and hardlinks are only one minor advantage. You should really update the filesystem to NTFS using the on-board convert.exe tool. As for X, it should have a fallback method if the /tmp filesystem doesn't support hardlinks. Well, the fallback method is to use -nolock :-) The only use of the lock file appears to be to stop people from doing things like starting 'X :0 -nolisten inet -nolisten inet6' and 'X :0 -nolisten unix' at the same time, so I'm kind of tempted just to make '-nolock' the default and let people run with scissors if they want to :-) However, since there does seem to be some code to grovel over the mount options to try to detect if /tmp is textmode and warn about that for some reason, perhaps I'll look at checking if it's FAT and turning off the lockfile automatically in that case. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file
On Nov 11 07:40, Fergus wrote: Q1. Is it still the case that this problem is not well understood as in this reference? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file Hardlinks don't work on FAT filesystems since FAT doesn't support them. Up to Cygwin 1.7.0-60, hardlinks on FAT were faked by copying the file. This has obvious downsides (unsecure, potential denial-of-service problems, portability), so we discussed and decided to remove this fake and to return an error instead when trying to create a hardlink on a FAT FS: http://cygwin.com/ml/cygwin/2009-09/msg00208.html (My experiments with possible cause/ cure are confounded because on Machine 1 I have NTFS filesystems but lack administrator rights and on Machine 2 where I am Administrator, all filesystems are FAT32.) Which is bad since FAT32 has no security at all. Any process of any user on the machine can overwrite any file, even in the Windows folder. NTFS is much more secure and has a couple of features you never get with FAT32, and hardlinks are only one minor advantage. You should really update the filesystem to NTFS using the on-board convert.exe tool. As for X, it should have a fallback method if the /tmp filesystem doesn't support hardlinks. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file
On 11/11/2009 02:40 AM, Fergus wrote: Q4 Why are questions about X specifically directed to a different mailing list? Apart from occasional high-frequency dialogue as at present, posts about X are (or seem to me to be) no more frequent than posts about grep or ls or chmod or ... . The main Cygwin list has a much higher readership and posts directed there might generate many useful hints, tips, experiences, fixes or even solutions? Except in the cases where the issue at hand just looks like a X problem but is instead a Cygwin problem, I don't see that being on a separate list minimizes the knowledgeable readership. That is, unless those with X background don't know about the Cygwin-X list. But if that's the case, they may not really fall into the knowledgeable category. ;-) And in the case where it is a Cygwin vs a X problem, these questions get redirected to the main list AFAICS when appropriate. I believe the original intent was to keep X separated from the high volume of the regular list rather than the other way around. The last time this question came up, the consensus supported that notion. Of course, things could change in the future. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Can't read lock file
I have made no alterations/ patches/ amendments and have a completely current [1.7] system. For all of cygwin1.7.61.dll - cygwin1.7.64.dll the command run XWin fails with a reference to /vat/log/XWin.0.log which reads Can't read lock file /tmp/.X0.lock But when reverting to cygwin1.7.60.dll everything goes ahead smoothly and correctly and I can start a X terminal etc. Q1. Is it still the case that this problem is not well understood as in this reference? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file (My experiments with possible cause/ cure are confounded because on Machine 1 I have NTFS filesystems but lack administrator rights and on Machine 2 where I am Administrator, all filesystems are FAT32.) Q2. Is there anything obvious in the progression from cygwin1.7.60.dll to cygwin1.7.61.dll that might explain why the start command run XWin works with 1.7.60 and fails with 1.7.61? Finally Q3. Confession: I am completely confused by all recent posts about LANG, locale and all the rest. Are fiddling with LANG or applying patches such as described at http://cygwin.com/ml/cygwin-xfree/2009-11/msg00071.html fixes intended to address problems starting XWin? Thank you. Fergus PS Not quite finally. Can I please ask a 4th question: Q4 Why are questions about X specifically directed to a different mailing list? Apart from occasional high-frequency dialogue as at present, posts about X are (or seem to me to be) no more frequent than posts about grep or ls or chmod or ... . The main Cygwin list has a much higher readership and posts directed there might generate many useful hints, tips, experiences, fixes or even solutions? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Can't read lock file problem: Cygwin/X FAQ solution doesn't work for me
Cygwin gurus, After happily using cygwin-X for many years, I have just encountered my first true frustration. After updating my cygwin distribution earlier this week, I found that I can no longer start X windows, getting the same can't read lock file that other users have experienced. I tried the solution from the Cygwin FAQ (http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file): $ rm -rf /tmp; mkdir /tmp ; chmod 1777 /tmp; xinit -nolock but this did not help. Same problem. Here is some more info that hopefully would help, and I'd be happy to work with someone more knowledgeable to try to diagnose and fix the issue: $ more /var/log/Xwin.0.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.5.3.0 (10503000) Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: X :0 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1440 h 900 winInitializeDefaultScreens - Returning Fatal server error: Can't read lock file /tmp/.X0-lock $ ls -sail /tmp total 0 1688849860281053 0 drwxrwxrwt+ 3 rsignell Domain Users 0 Dec 4 07:07 . 281474976792025 0 drwxrwx---+ 13 rsignell Users0 Dec 4 06:26 .. 37717646879254565 0 drwxrwxrwt+ 2 rsignell Domain Users 0 Dec 4 07:07 .X11-unix Thanks, Rich -- Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file problem: Cygwin/X FAQ solution doesn't work for me
Rich Signell wrote: Cygwin gurus, After happily using cygwin-X for many years, I have just encountered my first true frustration. After updating my cygwin distribution earlier this week, I found that I can no longer start X windows, getting the same can't read lock file that other users have experienced. I tried the solution from the Cygwin FAQ (http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file): $ rm -rf /tmp; mkdir /tmp ; chmod 1777 /tmp; xinit -nolock but this did not help. Same problem. xinit -nolock is not the right syntax for starting the server with -nolock. As 'man xinit' says, server options follow a '--', so try 'xinit -- -nolock' I did wonder if this is somehow related to running as a user who does not have administrator rights. Is this true in your case? Can you provide the output of 'strace Xwin' , please. Here is some more info that hopefully would help, and I'd be happy to work with someone more knowledgeable to try to diagnose and fix the issue: $ more /var/log/Xwin.0.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.5.3.0 (10503000) Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: X :0 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1440 h 900 winInitializeDefaultScreens - Returning Fatal server error: Can't read lock file /tmp/.X0-lock $ ls -sail /tmp total 0 1688849860281053 0 drwxrwxrwt+ 3 rsignell Domain Users 0 Dec 4 07:07 . 281474976792025 0 drwxrwx---+ 13 rsignell Users0 Dec 4 06:26 .. 37717646879254565 0 drwxrwxrwt+ 2 rsignell Domain Users 0 Dec 4 07:07 .X11-unix -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fwd: Xwindows won't start (Can't read lock file)
James Ertle wrote: Fatal server error: Can't read lock file /tmp/.X0-lock As a workaround, you should be able to add -nolock to the command line used to start Xwin (in startxwin.bat, I'm guessing, in your case). Since a few people seem to have this problem, I'd like to get a resolution. Sadly, I have no theory about how this could be happening, except perhaps it could be related to 'unusual' permissions on /tmp which could somehow let you create but not rename a file (so the output of 'ls -al /tmp' might enlighten) Also of note - I don't see xorg-x11-base as a choice when installing, and I no longer see an entry for the startup scripts... These are now obsolete as explained here: http://cygwin.com/ml/cygwin-xfree-announce/2008-11/msg0.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fwd: Xwindows won't start (Can't read lock file)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon TURNEY wrote: Sadly, I have no theory about how this could be happening, except perhaps it could be related to 'unusual' permissions on /tmp which could somehow let you create but not rename a file (so the output of 'ls -al /tmp' might enlighten) /tmp should be 1777. Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkcnpAACgkQpiWmPGlmQSNWigCg6vcBztFimUfoz+xMIHowTb4j UFMAoPCdsTYDsGKJgZo+z92OI/YLrHhu =+APH -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fwd: Xwindows won't start (Can't read lock file)
Jon TURNEY wrote: James Ertle wrote: Fatal server error: Can't read lock file /tmp/.X0-lock As a workaround, you should be able to add -nolock to the command line used to start Xwin (in startxwin.bat, I'm guessing, in your case). Since a few people seem to have this problem, I'd like to get a resolution. Yaakov, Ok, my archaeological investigations in this area have revealed that this locking code probably wasn't enabled in 6.8.99. I don't think it is actually giving any benefit, since we also have a native named mutex is used in the DDX code to prevent multiple servers with the same display number, before that locking code is entered. So, it might be expedient to disable this locking code for now, since it seems to be generating problems. Attached is a quick patch to do that. Note that SERVER_LOCK as a configuration has been removed in X.Org git master, making the patch to turn it off larger, so we might well have to cross this bridge again at a later date... Cygwin has a per-display mutex, so the lockfile in /tmp doesn't win us anything (and seems to cause problems) --- xserver/configure.ac |1 - 1 file changed, 1 deletion(-) Index: xorg-server-1.5.3/xserver/configure.ac === --- xorg-server-1.5.3.orig/xserver/configure.ac +++ xorg-server-1.5.3/xserver/configure.ac @@ -1086,7 +1086,6 @@ AC_SUBST([VENDOR_RELEASE]) AC_SUBST([VENDOR_MAN_VERSION]) AC_DEFINE(DDXOSINIT, 1, [Use OsVendorInit]) -AC_DEFINE(SERVER_LOCK, 1, [Use a lock to prevent multiple servers on a display]) AC_DEFINE(SMART_SCHEDULE, 1, [Include time-based scheduler]) AC_DEFINE(NO_LIBCWRAPPER, 1, [Define to 1 if modules should avoid the libcwrapper]) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fwd: Xwindows won't start (Can't read lock file)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon TURNEY wrote: Ok, my archaeological investigations in this area have revealed that this locking code probably wasn't enabled in 6.8.99. I don't think it is actually giving any benefit, since we also have a native named mutex is used in the DDX code to prevent multiple servers with the same display number, before that locking code is entered. That may help for XWin, but what about all the other servers? They do rely on the locks to prevent multiple servers on the same display. The question is really *why* this is causing problems. I haven't seen this, and AFAIK neither have you. My /tmp is 1777; has anyone with this problem tried that? Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkcyIgACgkQpiWmPGlmQSP7ogCfWZ3FWWfOb263nUG/3Hi+0N0a ij8An2+9LKyMBvMAH4yJyYp7EppfS/Lt =XhkS -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
