s9y testdrive

Logged in to my Mac App Store account today, the "Purchases" tab greeted me with an update for Xcode. However, clicking on it only resulted in the following:

  You have updates available for other accounts.
  Sign into the account you used to purchase it.

Huh? I don't have any other accounts. One Apple account is more than enough :-\
So, what's the deal here? Luckily, others had similar issues and a solution as well. Either one should do:

• Delete or move /Applications/Install Xcode.app resp. Install XCode.dmg, usually found in /Applications as well. Then try again to update Xcode.
• Refresh your Spotlight index. I.e. add/remove your system disk to the index, then try again to update.

Sure, Disk Utility.app can be used to set up NFS mounts. But as long as automount(8) is supported in MacOS X, let's use this for a more general approach:

Create the mount points first, both for SMB and NFS:

  $ mkdir /mnt/{nfs,smb}/{a,b}

Then we create automount ''maps'' for each protocol:

 $ cat /etc/auto_nfs 
 /mnt/nfs/a -fstype=nfs,rw,resvport 10.0.0.10:/export/foo
 /mnt/nfs/b -fstype=nfs,ro,resvport 10.0.0.10:/export/bar
 
 $ cat /etc/auto_smb 
 /mnt/smb/a -fstype=smbfs,rw ://10.0.0.10/foo
 /mnt/smb/b -fstype=smbfs,ro ://10.0.0.10/bar

With that in place, we have to include both files in auto_master(5)

 $ grep -v ^\# /etc/auto_master
 +auto_master            # Use directory service
 /-                      auto_smb
 /-                      auto_nfs

Tell automountd(8) to flush any cached information:

 $ automount -v -c

Sometimes it's necessary to restart automountd:

 $ launchctl stop  com.apple.automountd
 $ launchctl start com.apple.automountd

Now the shares should be mounted automatically upon access.

Whooha, auch der CCC macht mit!

Update: theoatmeal.com had a good explanation why SOPA/PIPA is not a good idea:

While extracting a tarball, GNU/tar told me:

Ignoring unknown extended header keyword `SCHILY.dev'
Ignoring unknown extended header keyword `SCHILY.ino'
Ignoring unknown extended header keyword `SCHILY.nlink'

Hm, what does that remind me of? Ah, star! Digging in the bits still left on BerliOS, there seems to be something what looks like a POSIX proposal:

$ cat star/README.posix-2001
[...]
        Star supports the following fields in the extended header:
[...]
        Vendor unique:
        "SCHILY.devmajor" "SCHILY.devminor"     (create/extract)

        In -dump mode (a preparation for incremental dumps) star archives:

        "SCHILY.dev"            The field stat.st_dev   - the filesys indicator
        "SCHILY.ino"            The field stat.st_ino   - the file ID #
        "SCHILY.nlink"          The field stat.st_nlink - the hard link count
        "SCHILY.filetype"       The real file type      - this allows e.g.
                                                              socket/door

Wow. Alas, these headers remain unrecognized in GNU/tar, hence the (benign) warnings.

Learn something new every day: I'm trying to test if a directory on a different filesystem is writable. Instead of really writing to it (e.g. by using touch(1)), I wanted to test with -w:

$ ls -ld /mnt/usb/foo
drwx------ 13 root root 4096 Jan  1 15:38 /mnt/usb/foo

$ [ -w /mnt/usb/foo ]; echo $?
1

OK, /mnt/usb/foo is not writable, because /mnt/usb was mounted read-only at this point. But look what dash(1) thinks of this:

$ [ -w /mnt/usb/foo ]; echo $?
0

Huh? But the manpage explains:

-w file  True if file exists and is writable. True indicates only that the write flag is on.
         The file is not writable on a read-only file system even if this test indicates true.

...whereas bash(1) only states:

-w file  True if file exists and is writable.

Zsh and ksh93 behave just as bash - that is returning 1 when the file is not writable, even though its permissions would allow for writes. Note that /usr/bin/test is shell-specific as well!