Wednesday, July 04, 2007

Cygwin on Microsoft Vista

I've run into a few problems using Cygwin on Microsoft Vista on my new laptop:

  • The installation hung during the post-install step "/etc/postinstall/gnuplot.sh". Researching this problem on the google found an article on the cygwin mailing list which worked around the problem by setting the Windows XP compatibility mode on the installation executable. I wasn't comfortable with this solution as it might cause things to not work well later on Vista.

    So I poked around a bit, turned on the "Command Line" output for the "Processes" tab in the Windows Task Manager and found that the script was hanging on "/usr/bin/texhash", which rebuilds a directory listing used by Tex. I was able to run the command successfully on the cygwin command line, but it was still hung in the installation process. So I used Task Manager to kill the texhash process and the installation continued to a later step "postinstall-ec-fonts-mftraced.sh" where it was trying to run "mktexlsr" - which is the same program. I again used Task Manager to kill that process and the installation now went on to a succesfull completion.

    Following the install, I went back and ran the texhash program manually, which did require me to change the mode of the files "/var/cache/fonts/ls-R" and "/usr/share/texmf/ls-R" files which had been left read-only when I killed the process.

    Everything seems to be working fine now.

  • Scripts moved over from my Windows XP installation of cygwin now fail to run because they are DOS formated (\r\n line termination vs UNIX's \n). I don't recall setting anything special when I installed cygwin on my old system, but on the new install, it clearly asked if I wanted to use the binary (UNIX) mode vs DOS mode and recommended Binary (which I picked). Not a big deal... Just ran "tr -d '\015' < file > file.new" for any such scripts to get rid of the \r's
  • My rsync backup scripts failed with strange errors and paths. I poked around a bit and this seems to be caused by the extensive use of NTFS's Junction points within the c:\users\user_name profile directory (including a particularly problematic one where "c:\users\user_name\AppData\Local\Application Data" points back to "c:\users\user_name\AppData\Local" creating an infinite loop, even for Windows Explorer (you can infinitely open "Application Data" again and again going as deep as you want since at every stage you get the contents of "Local" again which has the "Application Data" junction again within it).

    Junction points look like a shortcut in Windows Explorer and behave like a Unix symbolic link to some extent. I couldn't find anything within the cygwin mailing lists, nor in the rsync man page to deal with this problem, so I just manually excluded the problematic entries from the backup set and things worked fine.

Tags : /

4 comments:

dashnu said...

Thanks for this. Worked for me as well.

jeromeg said...

same thing here, it worked for me as well. Thanks.

Anonymous said...

This problem appears to be related to the Vista installer detection feature.

(Vista installer detection will try to run install, setup, update, etc with administrator privelege).
Apparently the installer detection feature will mess up /usr/bin/install and postinstall also.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1021146&SiteID=1

This is by design.
Look for installer detection in: http://download.microsoft.com/download/5/6/a/56a0ed11-e073-42f9-932b-38acd478f46d/WindowsVistaUACDevReqs.doc

You can turn off that specific feature:
secpol.msc -> Security Settings -> Local Policies -> Security Options ! UAC: Detect application installations and prompt for elevation

Matt said...

A fix that worked really well for me, based upon what I had seen here, was to go to Compatibility on the properties sheet for the setup executable, but instead of setting WinXP compatibility, I set "Run as Administrator." This solved the problem. Then, of course, I switched off the Run as.