unsigned long geek = random();

A few months ago while working on a Linux system using XFS, I came across an interesting “feature”. When moving a directory such that its owner changed, the moved directory’s mtime was changed to the current date and time.

For example:

[0] mj@majestic:~/tmp$ mount |grep home
/dev/mapper/data-home on /home type xfs (rw)
[0] mj@majestic:~/tmp$ mkdir test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jun 18 15:28 test
[0] mj@majestic:~/tmp$ touch -t 200801011530 test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test
[0] mj@majestic:~/tmp$ stat test
File: `test’
Size: 6 Blocks: 0 IO Block: 4096 directory
Device: fd00h/64768d Inode: 951267331 Links: 2
Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-01-01 15:30:00.000000000 +0000
Change: 2008-06-18 15:29:08.173750666 +0100
[0] mj@majestic:~/tmp$ mv test test1
[0] mj@majestic:~/tmp$ ls -ld test1
drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test1
[0] mj@majestic:~/tmp$ mv test1 ..
[0] mj@majestic:~/tmp$ ls -ld ../test1
drwxr-sr-x 2 mj mj 6 Jun 18 15:30 ../test1
File: `../test1′
Size: 6 Blocks: 0 IO Block: 4096 directory
Device: fd00h/64768d Inode: 951267331 Links: 2
Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-06-18 15:30:02.814078187 +0100
Change: 2008-06-18 15:30:02.814078187 +0100


I’d never seen this happen before, so I tried to reproduce the behaviour on systems using ext3, UFS and HFS+ filesystems. None of them updated the moved directory’s mtime when the parent directory changed, which is what one would expect. XFS does have an active mailing list, so I reported my findings and was quickly provided with a patch that fixed the problem. Kudos to the XFS developers for providing a fix so quickly.

Rather odd that no-one had spotted this behaviour in the past though…

I’ve obviously been living in a cave for a while, but I only recently discovered that Panix are offering “virtual colocation” via Xen virtual machines. One very nice feature - they offer NetBSD in addition to the customary Linux. Pricing is competitive and they also offer a free backup service, which is a nice addition. Not quite sure why their default NetBSD virtual machine includes X11 though?

I upgraded my notebook to Linux kernel 2.6.18 about a month ago, shortly it was released. One thing that is greatly improved is the stability of suspending to disk. I use Suspend 2 and with various patchlevels of 2.6.17 it would sometimes not suspend properly, necessitating a reboot. Things seem a lot better after the upgrade - I haven’t yet had a suspend fail, touch wood.

Sadly, my laptop still generates spurious ACPI overheating events, which cause an unwanted shutdown. That’s something I’ll probably have to fix with a new DSDT or by patching the kernel myself to ignore nonsensical temperatutes (783 degrees!).

Today I upgraded to VMware Workstation 5.5.2 on my notebook, which runs Debian testing. When I started VMware, I got the following in a terminal window, but the VMware window didn’t appear:

/usr/local/lib/vmware/bin/vmware: /usr/local/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/bin/vmware: /usr/local/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)


After a bit of judicious Googling, it seems that the above libpng errors are red herrings and that the problem is caused by an incorrect libdbus being loaded by VMware. The solution is to preload the correct version of libdbus. For more information, including a solution, see this thread on the VMware forums. Apparently newer versions of Ubuntu exhibit the same problem.

As Rafiq says, our local LUG is in need of sponsorship for its stand at this year’s Futurex exhibition. About half the money needed (R10,000 - about US$ 1,250) has been collected so far, but we still need every donation we can get. For more info on donating, see the sponsorship page on the CLUG site.

I’ve made my donation (guess who I am on the list - have you?

I see that Sun were offering a reward for the porting of Linux to their CoolThreads-based systems (a reward I’m sure has been claimed now that David S. Miller has Linux booting multi-user on such systems). Come on Sun - why not offer the same reward for porting NetBSD to CoolThreads? After all, SunOS releases prior to 5.x were based on BSD and Sun has made past donations to The NetBSD Foundation.

There’s been quite a bit of buzz over the past few months about Xgl, the X server architecture layered on OpenGL. Although still in the early stages of development, some code has been released and there are numerous guides explaining how to get Xgl running on a Linux system (the Gentoo Wiki has a good run down of what to do).

Until quite recently, Xgl was only supported on machines that could use the proprietary ATI or NVidia X drivers, which excluded me, as my laptop has an Intel 915DM display subsystem (one of those horrible shared memory systems). This has since changed and the 915DM is now supported. Rather fortuitously, today Jonathan kindly passed along a copy of the latest Gentoo-based Kororaa Xgl Live CD 0.2. When I booted it on my laptop, I was very impressed with what I saw - the performance was good (much better than, for example, the composite extension of X.org 6.9, as I’m using currently) and the eye candy certainly is purrty

After my post a few days ago about GRUB, and a boot loader discussion on the mailing lists of our local LUG, I’m reminded of Thor Lancelot Simon’s post to the NetBSD port-xen list about GRUB. He makes quite a convincing argument that GRUB is less than ideal:

The code is revolting, the user interface is opaque and highly buggy, it exhibits the “I know better than the user” interface paradigm as much as almost any system utility I’ve ever seen (note how it’s impossible to run “grub-install” on a root-on-RAID netbsd system because it *ignores* the “impossible” values in the disk map even if the correct values were hand-entered there), it is poorly documented, it doesn’t know how to pass arguments to a modern NetBSD kernel, and, even worse, the support for booting BSD kernels *at all* relies on header files copied directly from an old version of FreeBSD with their copyrights stripped off in blatant violation of the BSD license.