Skip to content

XCode: You have updates available for other accounts

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? (Un)fortunately, others had similar issues and a possible solution as well:
  • 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:
     $ launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
     $ mdutil -a -i on && mdutil -a -E
    
    Now the AppStore should work again. Disable once the updates are completed:
     $ mdutil -a -i off
     $ launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
    
Update: Since I have disabled Spotlight, refeshing the index would not work. Upon adding/removing items from the list of excluded directories, this happens:
 Privacy List Error
 The item couldn't be added or removed because you don't 
 have the appropriate permissions.
So we have to enable Spotlight again:
$ launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

$ launchctl list | grep -i metadata
5035    -       com.apple.metadata.mds
-       0       com.apple.metadata.mds.spindump
-       0       com.apple.metadata.mds.scan
Now refreshing Spotlight's index should work and AppStore will be able to install software again. We might choose to disable Spotlight again:
$ launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

MacOS X automount

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.

Ignoring unknown extended header keyword `SCHILY.dev'

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.

test -w

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! -- Not anymore? Let's try again:
$ mount | grep /mnt
/dev/loop0 on /mnt type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl)

$ bash -c "[ -w /mnt ]"; echo $?
0

$ dash -c "[ -w /mnt ]"; echo $?
0

$ bash -c "/usr/bin/test -w /mnt"; echo $?
0

$ dash -c "/usr/bin/test -w /mnt"; echo $?
0
And now for the read-only mount:
$ mount | grep /mnt
/dev/loop0 on /mnt type ext2 (ro,relatime,block_validity,barrier,user_xattr,acl)

$ bash -c "[ -w /mnt ]"; echo $?
1

$ dash -c "[ -w /mnt ]"; echo $?
1

$ bash -c "/usr/bin/test -w /mnt"; echo $?
1

$ dash -c "/usr/bin/test -w /mnt"; echo $?
1