Twitter Updates

    follow me on Twitter

    G-AVLN in front of her home

    G-AVLN in front of her home

    Mostly Unix and Linux topics. But flying might get a mention too.

    Wednesday, July 14, 2010

    Creation time in UniX? Yes - in ext4

    The ext4 file system has now been available for a while, but so far Ubuntu is the only distribution installing it by default.

    There are significant differences between ext4 and its predecessors, and amongst them is extent mapping (instead of the traditional indirect block mapping), the new 1 nanosecond date resolution capability, date limit pushed back till 25/04/2514, and for the first time in UNIX i-node that stores five file timestamps (i-node width defaults to 256 bytes in ext4).

    In addition to the traditional atime (a=access), mtime (m=modification) and ctime (c=change of i-node), in ext4 we now also have crtime (cr=creation) and dtime (d=deletion).

    It's this creation time that many people insisted on having... So we now have it. There is one problem, though. Standard Linux tools can't yet deal with this sophistication!

    Normally, we would use tools like stat or find to read file attributes from their i-nodes, but at the moment, they are not extracting any more information from ext4 than from ext2 or ext3.

    This is where debugfs can help. First, check which partitions are formatted with ext4:

    # mount | grep ext4

    /dev/sda1 on / type ext4 (rw,errors=remount-ro)

    Here, the root file system is ext4. To see all know timestamps on a file in this file system (for example, for /etc/hosts file):

    # debugfs -R 'stat /etc/hosts' /dev/sda1

    Inode: 133370 Type: regular Mode: 0644 Flags: 0x80000

    Generation: 1995841318 Version: 0x00000000:00000001
    User: 0 Group: 0 Size: 250
    File ACL: 0 Directory ACL: 0
    Links: 1 Blockcount: 8
    Fragment: Address: 0 Number: 0 Size: 0
    ctime: 0x4c080d16:0bf9435c -- Thu Jun 3 21:14:14 2010
    atime: 0x4c3da303:c11dd858 -- Wed Jul 14 12:44:03 2010
    mtime: 0x4c080d16:0bf9435c -- Thu Jun 3 21:14:14 2010
    crtime: 0x4c080d16:0bf9435c -- Thu Jun 3 21:14:14 2010
    Size of extra inode fields: 28
    (0): 557470

    Alternatively, check its i-node number (with ls -i) and run debugfs aganist it (notice the compulsory angle brackets if using i-node number):

    # debugfs -R 'stat <133370>' /dev/sda1

    Inode: 133370 Type: regular Mode: 0644 Flags: 0x80000

    Generation: 1995841318 Version: 0x00000000:00000001
    User: 0 Group: 0 Size: 250

    At last!

    BTW, I'm being told perl can extract the crtime from the i-node, but haven't tried it yet...

    Thursday, July 01, 2010

    Update your SSL certificate for Citrix

    Some time ago I wrote in this blog a little tutorial on how to install and configure a Citrix client in Linux. The solution worked then, and still works today (I am now on 64-bit Ubuntu 10.04).

    However, some weeks ago, I started getting "You have chosen not to trust..." message when connecting. Unfortunately for me, it coincided with a new laptop build, and I have assumed that my configuration has gone awry. My new system was built from scratch, but the home directory was restored from an rsync backup of my old laptop. That managed to confuse me, in that I suspected that some of the start-up files imported from the old (32-bit) laptop conflicted with the new (64-bit) system. It kept me going! I have repeated my own instructions several times, trying other browsers, googling if others had anything similar issues. The overwhelming set of instructions kept referring to the lack of the certificate in the correct ICAclient location. I have double and treble checked that part of the setup, and all seemed well, but the problem persisted.

    Having spent several hours on dissecting the problem and getting nowhere, I suddenly relised that all proposed solutions refer to a couple of certificate authorities, whereas my error message referred to something totally different. Went to their site, and it turned out that my certificate that, I had been using for years, has been updated (even though it was meant to be valid till 2020). Anyway, a new download of the certificate into the keystore:

    (an operation that in itself took about 15 seconds) and the problem was sorted.

    Blog Archive