After setting up the alignment according to some tutorials I found online, I started the setup process. Shortly after starting the copy step of the installation, the whole process came to a grinding halt with filesystem errors. Looking into the kernel debug messages it seemed like SATA commands were causing errors. After checking hardware, cables and switching SATA ports, I began researching the issue and soon found that the issue might be fixed in the next firmware version of the drive. So I wanted to upgrade from 1.23 to 1.24, which could only be done in Windows…

After installing a trial of Windows 7, I finally wanted to upgrade the firmware, but the drive was not detected, but was accessible. The release notes indicated that I would need to switch to AHCI mode. After several attempts, includig a BIOS update, I realized that there was no way to do this with my old hardware, as my nForce 430 chipset simply doesn’t support it.

So my only remaining option was to simply try the kernel arguments I read to be the fix for 1.24 with the 1.23 hardware.

So, if you add the following kernel option during installation and afterwards for every boot, the disk seems to work quite well (source):

libata.force=norst

Actually, this forces the ATA driver in Linux to not issue any reset commands on the bus. I really don’t understand why this improves/fixes the problem, but it seems the device has issues when being reset on my chipset. I can also notice this that in 2 out of 3 attempts if I reboot the PC the disk is not recognized any more before I reboot again.

Despite these issues, the SSD now runs with astonishing performance with the suggested 32 head / 32 sector alignment, and a 512kB partition alignment scheme. After an initial TRIM with hdparm‘s wiper.sh I enabled -o discard for my ext4 partition and could also verify using hdparm that this results in the sectors being trimmed. Please note, that you need to manually compile and install the latest hdparm version on Ubuntu 10.10, as the included version fails with the very long free block list and doesn’t handle splitting the sectors in multiple requests. The latest version doesn’t have this issue any more.

PostScript files are almost plain-text files, and if you set core.autocrlf and core.safecrlf, they might cause problems with the EPS binary encoded parts, as they might be detected as text-files and therefore remove any CRLF and replace it with single LF, which can mess up the whole image.

To force Git to consider a file binary which it would consider as text-file otherwise, the easiest way is to add a .gitattributes file to the directory containing the file or to any parent directory. In my case, I normally add a .gitattributes file in the root of the repository, containing

*.eps -crlf
*.jpg -crlf
*.png -crlf

In the file you set attributes to a path (or a pattern), or unset them (with the minus sign).  The crlf attribute is the attribute which tells if a file is affected by the core.autocrlf options. If you unset it, Git won’t mess with the line endings in the file.

More details can be found on the gitattributes man page.

It seems there is a little bug with the installation on Vista under certain circumstances which causes the extensions not being registered properly with OO.org.

To solve the problem, follow the same following steps:

• Locate your OO.org “install” directory of your installation, usually it is C:\Program Files\OpenOffice.org 3\share\extensions\install” [Updated 2008-12-21 to include "extensions", thanks to the anonymous commenter!]
• Manuylla install the appropriate dictionary extension (“dict-en.oxt”, “dict-de.oxt”, “dict-fr.oxt”, “dict-it.oxt”) by either launching the oxt directly or by chosing Tools -> Extension Manager.

For me this worked after restarting OO.org totally (i.e. closing down all Writer, Calc, …).

$ git svn dcommit
6 [main] perl 4760 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\cygwin\lib\perl5\site_perl\5.8\cygwin\auto\SVN\_Core\_ Core.dll to same address as parent(0x260000) != 0x990000 84 [main] perl 3224 fork: child 4760 - died waiting for dll loading, errno 11 panic: MUTEX_LOCK (45) [util.c:2331] at /usr/bin/git-svn line 787. panic: MUTEX_LOCK (45) [op.c:352].

The reason behind this behavior is a huge difference in the way processes and threads and libraries are created/handled on Windows and Linux. git-svn relies on perl within cygwin and several perl libraries that use the same base-address for libraries internally. Of course, no two libraries can be loaded to the same base-address at the same time.

Long explanation, short way to fix the problem:

1. Quit all cygwin processes
2. Start ash (<cygroot>\bin\ash.exe) (<edit>Use “Run as Administrator…”</edit>)
3. Execute /usr/bin/rebaseall

Voilla, that’s all. git-svn should work again.

As the easiest workaround, you should perform the following steps:

• Once you get notified about the update and you are asked if you want to install it, say “No”.
• Close the Mozilla application in question.
• Search for the application in your “Start” menu.
• Right-click the entry and choose “Run as Administrator…”
• Choose “Check for Updates…” in the “Help” menu
• Confirm you want to install the update and walk through the update process.

The installation will now work. For security reasons you should close the application once installation is finished, because it will still be running with elevated privileges. Now start the application again normally.

The same principle works for any application that is not Vista-aware and fails on automatic update. For security reasons make sure you keep the time you run with elevated privileges as short as possible.

What I really love about Git is the fact that it nicely integrates with existing Subversion repositories. At our company, we are using Subversion as our SCM, but I personally like Git more and I want to use it as a side tool for more flexible branching, merging, and for checking in versions I wouldn’t check in the shared repository.

Git is supplied with git-svn, which can import an existing SVN repository and also commit back to it. Under cygwin, you need to perform two additional steps for getting git-svn to work, otherwise it is likely to fail with “failed to include Error.pm”.

• subversion-perl (install via cygwin‘s setup.exe)
• Error.pm

You need to download Error.pm from CPAN. You have to save it to <cygwin-dir>\lib\perl5\Error.pm

Voila! git-svn should work now.

If you are using Git under Windows using cygwin, and you got through the initial problems, you will soon realize that Git likes to fail with “You have some suspicious patch lines” when committing.

The cause for this problem is the carriage-return/line-feed problem of Git under Windows/cygwin: The patches contain a trailing line-feed if you edited them with a Windows editor and not strictly inside cygwin. This will trigger the pre-commit hook to fail on patches where the last line of a file has been changed.

To solve the problem, you need to edit .git/hooks/pre-commit and comment out the following lines:

if (/\s$/) {
bad_line("trailing whitespace", $_);
}

Now committing should work.

First, I ran into troubles installing cygwin. I figured out, that it seems to work well if you run both the installer and bash in “Windows XP SP2 compatibility mode”. I needed to adjust the file system permissions of the cygwin folder to give me write permissions, though. (Note: you have to manually install the TK-libs if you want the GUI elements of git to work.)

But Git kept failing with “access denied” messages when trying to commit from command line. The failure message said it was denied access to git-update-index. I soon found out this is due to the “User Account Control” (UAC) default behavior of auto-detecting installers and prompting if you want to execute them with raised privileges. You can see if this is the case by running git-update-index manually from bash; if you get the UAC confirmation dialog you have this problem. It seems the substring “update” triggers this behavior. As the git-update-index is launched by git commit, it won’t display the confirmation dialog of Vista, so the execution will be denied.

There are two possible workarounds:

• Run bash with administrative privileges (not recommended!)
• Disable the auto-detection of installers by UAC.

I used the latter way. You can disable the auto-detection by following these instructions. Brief summary:

• Open the Local Security Policies
• Disable “User Account Control: Detect application installations and prompt for elevation”
• Reboot (the security policy will not be updated before!)

It should work now. You can confirm this by running git-update-index manually again. If you do not get the UAC confirmation dialog now, it worked. Try git commit now, and verify it is working. Of course, you will from now on have to right-click and “Run as Administrator” every installer you want to install, as most installers will require administrative privileges.

Update 2007-08-22: Reader EGarcia posted an interesting comment below: using the Microsoft Manifest Tool you can add an according manifest to the git-update-index.exe and git-update-ref.exe

Update 2009-02-12: Reader Kevin Broadey points out the best solution so far: create a seperate .manifest file for the affected files. He has provided an example for git-update.exe.manifest.

OpenVPN is my preferred tool for implementing low-cost VPN solutions for one reason: it simply works. It works very well on Linux and Windows. On Windows I commonly use one of the GUI frontends. On Windows, OpenVPN uses a virtual network card for the tunnelled data, the TAP Win32 Adapter, currently in version 8. Unfortunately this driver has a issue at the moment: the adapter works only once, after restarting windows the device has to be deactivated and reactivated, otherwise it will not come up after the connection to the VPN server has been established.

To get around this anoying issue I wanted to write a script that will reactivate before starting the GUI. As I soon found out, there is no way in standard Windows XP to (de)activate a device from a script. After some time I found a tool in Microsoft’s DDK which can also be downloaded seperately: devcon, a command line tool by Microsoft as an alternative to the Windows Device Manager.

First I needed to find the hardware id of the TAP device I wanted to restart:

> devcon findall *TAP*
ISAPNP\READDATAPORT\0 : ISAPnP-Datenleseport
ROOT\NET\0000 : TAP-Win32 Adapter V8
2 matching device(s) found.

Clearly I am interested in ROOT\NET\0000 in my case. This device can now be (de)activated with “devcon deactivate @ROOT\NET\0000” resp. “devcon activate @ROOT\NET\0000“. The @-sign is important!

As I wanted to explore some alternatives to Microsoft’s shell scripts (.cmd), I discovered KiXtart, a very powerful shell scripting language for Windows. Main advantage is, that KiXtart is able to run the script without showing an anyoing shell window during its runtime (which is the whole VPN connection in my case, as I want to disable the device after OpenVPN is shut down.

The script that needs to be executed is trivial: Instead of launching OpenVPN-GUI directly, I now launch the following KiXtart script from any shortcuts to OpenVPN GUI:

shell "devcon disable @@root\net\0000"
shell "devcon enable @@root\net\0000"
shell "C:\Program Files\OpenVPN\bin\openvpn-gui.exe"
shell "devcon disable @@root\net\0000"

The KiXtart interpreter requries around 1.4MB of RAM during the session (which I accept and don’t care about as my machine has 1.5GB of RAM installed). If you want to spare this amount and you don’t care that the device is not deactivated right after exiting OpenVPN-GUI, you could adapt the script to execute the GUI without waiting for its termination. You’d also have to remove the last line of the script. In this case you can also simply use standard Windows shell commands, as the shell will immideatly close after calling “start C:\...\openvpn-gui.exe“.