(sigh) It just made so much sense today...

Vista reparse shenanigans with rsync

As part of my backup script overhaul, I have switched to using rsync. The main reason is I now have to support Windows XP, Vista, Linux and maybe Mac in future; and I don't fancy re-doing all this backup stuff each time.

The good news first: rsync works a treat on Linux (well duh!) and XP (via cygwin). I was extremely happy with how easy to configure and quick to run the Linux and XP backup's were. But it seems I was fooled into a false sense of security...

I tried running exactly the same rsync script (that worked on XP) on Vista and was greeted with a slew of errors, the most confusing being:

rsync: /cygdrive/X/your-file-here: Permission denied (13)

Initially I thought it was the old Vista UAC playing up. But I confirmed that I had disabled UAC. The "permission denied" in this case, was a red herring. The real problem was the reparse points. These little symbolic links are available in XP, but not used much. But in Vista they really went to town, and scattered them all about the file system like the Easter Bunny hiding eggs.

rsync (well more likely the way it works with cygwin) is not too happy about reparse points, and after more careful inspection of my "Permission denied" errors, it turns out they were all on reparse points.

My hack to get around this is pretty simple. The backup script, just before running rsync, generates a list of all the reparse points and tells rsync to exclude them. Thus rsync never encounters a scary directory it doesn't know how to deal with.


VER | findstr /i "6.0.6000" > nul
IF %ERRORLEVEL% EQU 0 GOTO backup_vista
...rest of script...

backup_vista:
REM (dir) build a list of all the reparse directories
REM (sed) swap around the path separators
REM append to a file to use in rsync
dir c:\Users /A:LD /S /B | sed "s/c\:\\/\//;s/\\/\//g" >> exclude.local.list
dir c:\ProgramData /A:LD /S /B | sed "s/c\:\\/\//;s/\\/\//g" >> exclude.local.list rsync options --exclude-from=exclude.local.list /cygdrive/c/ destination
...rest of script...

It's not pretty, but (to quote Mr C. Monster) "it's good enough for me".

For bonus points, you could keep a copy of the reparse point list, and for a restore resurrect them all. I don't need this.

readynas is smokin' hot

I bought an Infrant ReadyNAS NV+ a little while back to "delay" (I dare not say "solve") some of our storage problems. It has worked perfectly for over 10 months and was, without doubt, the simplest computer equipment I have ever set up.

Unfortunately last weekend (after being out of the house all day, on a hot day) the expensive scent of burning plastic started to waft through the office. A brief nasal inspection of all the computer equipment revealed the fault was with the ReadyNAS. The stench of death lasted another 10 minutes before the unit switched off, never to return.

Fortunately it's still under warranty and should be RMA'd within the week, but it made me question my choice of the ReadyNAS. When I bought it, I was under the impression it was one of the most full featured and reliable home NAS devices you could get (I'm not a fan of Buffalo - dunno why).

After calming down, I remembered I was warned about this situation (and emailed) from Infrant way back in the cool of winter. I remember thinking "yeah - that's a good idea, I will do that..."

(so you know what that means)

I didn't, and now it's toast.

So tip of the day: If you have a ReadyNAS that needs the temperature patch and is not in an air conditioned office, apply the patch now.

It's still a great home NAS box and I would recommend it. But it's not quite as bullet-proof (when it comes to heat) as I hoped.

(song ends) ... Mono!

Lanley: And so, "mono" means "one." And "rail" means "rail." And that concludes our intensive three week course. [Marge vs. the Monorail]

Recently, I've been trying to offload a lot of scheduled processing from my desktop computer to a Linux (ubuntu in this case) server. One task that I thought might cause me some pain was XMLTV generation.

The general idea of the daily XMLTV task is:

1. Suck down the latest program listings with (the excellent) shepherd script. Unfortunately this is a necessary evil, since Australian copyright laws are pretty strange for television programming.
2. Augment the description field for each programme with the extra information shepherd provides. These are things like release year, episode name, director, actors, user ratings, etc. MythTV shows these extra details in the UI, but the MediaPortal UI does not currently show all this extra info. So the workaround is to cram it all into the description element (which is shown in the UI).

The old way to achieve this was to perform (1) on a ubuntu virtual machine (now no longer required as I have a real machine), and perform (2) on my desktop computer (Windows) via a little .Net 2.0 console program I cobbled together. Now that little program (or the logic it contained) needs to run on a real ubuntu machine.

I knew about the mono project already, but I had never actually tried to run it from scratch on existing code. The end result, after an easy 5 minutes was my existing code working perfectly on ubuntu.

1. Install the core mono package (mono) and the .Net 2.0 compiler (mono-gmcs)
   sudo apt-get install mono mono-gmcs
   
2. Run my existing (compiled in Visual Studio on Windows) executable on ubuntu with no recompilation or any other screwing around.
   mono xmltvAugment.exe
   

So easy.

This example was of course with a trivial .Net 2.0 console program. The program only used standard assemblies. But regardless, I was still impressed.

Ubuntu bits : System shutdown by power button

Simple enough problem: the headless server is sitting under the desk, the electricity needs to go off now (and you forgot to plug in the ups). You press the power button, nothing happens (as is normal).

Sure, you could just hold down the power button (or pull the plug). the file system will likely survive. Or you could fire up an ssh client and do a graceful shutdown. But if only that power button worked.


Well turns out the solution (for the next time it happens) is simple:

1. Make sure your ACPI support is all happy.
   
   dmesg | grep 'ACPI:'
   
   If it's not - then you need to enable it in the kernel.
2. Make sure ACPI has detected your power button.
   
   dmesg | grep 'ACPI: Power Button'
   
   If you have no luck, there's a kernel module you can load easily enough. Load it up, and check that it actually got loaded.
   
   sudo modprobe button
   lsmod | grep button
   
   Assuming all is well, add it to the boot time module list in /etc/modules
3. Use acpid to monitor ACPI events and shutdown when the power button is pressed.
   
   sudo apt-get install acpid
   
   That's it. The default acpid scripts will intercept the power button and force an immediate halt.
4. Optional : If you are really keen. Reboot, then:
   
   tail -f /var/log/syslog
   
   Then press the power button and enjoy the graceful shutdown.
5. Bonus Points: If you don't the default event handler, tweak /etc/acpi/powerbtn.sh till your content.