This morning, I wanted to get the wdiff package so I loaded up my setup only to find it was time to upgrade my setup. Uh, oh, looks like we're on 1.7 now so major upgrade just for this 1 package. >sigh< Well, as I was sleepless at 1a45 and had a few hours before work, and didn't want to manually select 'skip' for the hundred or so packages that were being marked for upgrade so that I can have fun with 1.7, I read the change log notes, decided I didn't care about /etc/fstab and all the other things seemed minor so what the hay...
So I do this, and, well, apart from the update updating qt3 then telling me that it and many other things are not updated on rerun then updating those then telling me 3 gnome packages and qt3 need updating so I update those so the same list of packages from before now need updating and back and forth like the dependancy tree is broken. Well, I say this but I doubt this be the issue but it probably explains the result of cygcheck reporting some incomplete, as can be seen below. But I provide that not to bore you but as back story to what I think is going on here. See, at first I could no longer run X. Eventually I found in the FAQ question 3.4: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file and, well, I have FAT on that machine (ostensibly for TiVo hacking) and so tweaking my shortcut to add "-- -nolock" to the "startxwin.exe" command, X came up like a charm. Then, I went to another machine and used my second favourite ssh option: "-Y" ("-L" is the first, in case you're wondering). And what do you think I saw? Our old friend: /usr/bin/xauth: creating new authority file /home/<uid>/.Xauthority /usr/bin/xauth: unable to link authority file /home/<uid>/.Xauthority, use /home/<uid>/.Xauthority-n The heck! Okay, so having read the FAQ and read and read and read so many articles hither and thither thanks to Google, I have come up with the theory that CygWin 1.7 breaks X11 Forwarding on a CygWin Host with a FAT32 file system because CYGWIN 1.7 changes how locks are performed and thus when sshd runs xauth it is unable to open ~/.Xauthority, creates ~/.Xauthority-n instead and does NOT set DISPLAY and does NOT allocate a display in /tmp as it used to. That is to say, ls -lauF /tmp/.X11-unix produces: drwxr-xr-x 1 <uid> None 0 2010-03-06 00:00 ./ drwxr-xr-x 1 <uid> None 0 2010-01-10 00:00 ../ srw-r--r-- 1 <uid> None 0 2010-03-10 00:00 X0= IIRC, there used to be an entry in /tmp/.X11-unix for each connected display, so I think the xauth isn't the only issue going on here. Also, I modified /etc/sshd_config to set XAuthLocation to "/usr/bin/xauth -v -i -b" and restarted the sshd service to force the server to break any locks on ~/.Xauthority if any exists before authenticating. Although this made the error go away, it didn't a) turn on verbose mode, since sshd adds '-q' to the parameter list of xauth, which disables '-v' and b) still doesn't create ~/.Xauthority. So, although I don't really want to go through the rigmarole of running convert.exe -- partly because I'm pretty sure there isn't enough free space on the drive to run it anyway -- I would consider it *if* I can be sure it's the only way I'll ever be able to X11 Forward again. So, can anyone confirm that xauth is permanently broken under FAT32? Or am I missing something? Thanks! Here's my cygcheck for my Win XP box... <cygcheck removed because I could not submit the original message; it was reported as s p a m!> -- 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/