Time Machine not Backing Up ?!

Recently my MacBook started to complain that it hadn’t been able to do a Backup successfully for the last 21 days !

My MacBook usually backs up regularly using Time Machine to a Volume shared from my Mac Mini (sharing a volume from another Mac is one of the few supported remote destination for backup options with Time Machine).

The volume was still shared from the Mac Mini but for some reason the MacBook didn’t see it when I connected via the Finder – other volumes and my home folder showed up fine though. Restarting the machines didn’t fix anything, so I resorted to Disk Utility to see if anything showed up there.

The only odd thing was that my Time Machine ‘server’ volume reported that “Owners Enabled” was “No” (at the bottom of the Disk Utility window). Disk utility doesn’t have a way to change/set this, but there is a command line utility you can run from Terminal that does :

vsdbutil -c /Volumes/TMServer
No entry found for '/Volumes/TMServer'.

If you run vsdbutil with the -a switch it will activate ownership on the specified volume :

bash-3.2# vsdbutil -a /Volumes/TMServer
bash-3.2# vsdbutil -c /Volumes/TMServer
Permissions on '/Volumes/TMServer' are enabled.

Once I re-enabled the Volume as a Shared Folder a Time Machine backup from the MacBook started almost immediately ! Success – Backups Restored !

Posted under Apple, Leopard

This post was written by awk on January 12, 2009

Tags: , ,

VMware at Macworld – Part II

What’s VMware showing at Macworld ?

Mac OS X 10.5 (Leopard) Server in a virtual environment.

This is an ‘out of the box’ install of Leopard running in an early (preview) version of a future VMware product for Mac OS X – yes it’s based on Fusion.

I’m really excited to be able to contribute to this (though I’ve done nothing yet, I’ve only been there a week 8-) – and I think that lots of people out there are looking forward to being able to use it too !

Posted under Apple, Leopard, VMware

This post was written by awk on January 15, 2008

Presentation at Boston CocoaHeads

I gave a presentation this evening at the monthly CocoaHeads meeting here in Boston. The topic was ‘Leopard Features in iOnTV’. You can download the slides of the presentation here.

Posted under Development, Leopard

This post was written by awk on November 8, 2007

Leopard Upgrades

I upgraded my Intel Mac Mini and PowerPC PowerBook this weekend with the final version of Leopard. Upgrading the Mac Mini was completely painless with no problems whatsoever.The PowerBook however was  more troublesome. After a backup using SuperDuper (always  backup before installing 8-) I began the upgrade. Why upgrade and not a clean or ‘archive’ install ? Well I don’t really have the disk space for an archive install (which moves the old /System folder aside and creates a new one), also I didn’t really feel like spending another couple of hours restoring all my old stuff – and hey upgrades are supposed to work !Shortly after beginning the install the Installer Application displayed an error dialog and told me to reboot with a message of ‘try again’. Unfortunately on the next reboot from the installation DVD my hard drives were ‘missing’ (don’t panic !) I know they’re still in the box somewhere -  but perhaps I will be doing a clean install after all ! Running Disk Utility from the installation DVD didn’t help. I’d had a problem during the Leopard betas where the Tiger partition (my drive has two partitions one for ‘seed’ releases the other for the current shipping version) would somehow get set to ‘invisible’ – it seemed like this problem had occurred in the middle of the installation !Fortunately I had a copy of TechWarrior DiskTools and ran the repair process – this seemed to recover everything back to how it had been before and this time the installation process worked fine…Until I launched Mail when it complained about ‘not having a keychain’. This too had an echo of the past – I remembered that a couple of years ago I had had a problem with a keychain also ‘disappearing’ magically. It too looked to have reoccurred. I launched the Keychain Access program and ran it’s ‘first aid’ option and saw that it was complaining about a ‘login’ keychain but no ‘awk’ keychain.  I took a gamble and copied the login keychain to awk (~/Library/Keychains/awk.keychain) reran the first aid option and things looked fine. Mail too was happy.So far everything else seems fine – I put my problems down to having a Tiger installation that’s ‘been through the wringer’ a bit over the years. 

Posted under Leopard

This post was written by awk on October 29, 2007


One of the new ‘developer’ features (i.e. a new API) in Leopard is ScriptingBridge. It’s a significant improvement to the mechanics of driving one application from another using AppleScript/AppleEvents.It’s always been possible to use NSAppleScript in Cocoa to send AppleScript to another application basically using a simple string :

NSString *appleScriptSource = [NSString stringWithFormat:@"tell iTunes to add (POSIX file \"%@\")", moviePath];

NSAppleScript *aScript = [[NSAppleScript alloc] initWithSource:appleScriptSource];

NSAppleEventDescriptor *aDescriptor = [aScript executeAndReturnError:&anError];

Not too bad, and you do get the returned data and in theory you can use that in subsequent scripts to affect the added track (adding metadata, setting it’s kind etc). However it’s slow and still really rather clumsy, and if you want to do any real argument munging you may be forced to revert to NSAppleEvent directly which is really painful and exceedingly longwinded.ScriptingBridge in Leopard makes this much, much more straightforward and friendly. Using the command line sdef and sdp tools you can create an Objective-C 2.0 header file which contains all the scriptable classes and elements of an application. Then you can include the header file and ScriptingBridge framework and the above code becomes:

iTunesApplication *iTunes = [SBApplication applicationWithBundleIdentifier:@"com.apple.iTunes"];

[iTunes setDelegate:self];

NSArray *filesArray = [NSArray arrayWithObject:[NSURL fileURLWithPath:moviePath]];

iTunesTrack *theTrack = [iTunes add:filesArray to:nil];

At first glance it looks like this is about the same code, but it executes much faster (no script parsing/compilation to AppleEvents). The returned object is a real Objective-C object so in the next line you can do :

theTrack.videoKind = iTunesEVdKTVShow;

theTrack.show = movieTitle;

Note – you can use Objective-C 2.0 style properties. Much neater than lines and lines of coded AppleScript. There is one catch – the header file is built from parsing the scripting definitions in the application (the sdef). These can still tend to be rather opaque – and in particular rather ‘type free’. AppleScript generally is a very weak typing language, and if you’re used to strong typing (C like) languages it can be a bit of a mind bending experience. In the iTunes case I struggled for a couple of days with the add: to: message – the generated header says :

- (iTunesTrack *) add:(NSArray *)x to:(SBObject *)to; // add one or more files to a playlist

There’s no indication of type for the contents of the array. Experience with ScriptEditor (and the initial NSAppleScript solution) suggested I should be able to just use an NSString in the array with the POSIX style path. However that failed with a ‘not found’ error when the message was sent. I initially thought it was a problem with the to argument needing to be a valid playlist and I spent quite some time convincing myself that I had a valid playlist argument (basically iterating things in the iTunesApplication object to get down to a playlist). Finally I went back to ScriptEditor and launched it from Terminal with the AEDebug=1 and AEDebugSends=1 environment variable set. This shows on stdout a debug of the AppleEvents that ScriptEditor sends. Looking at the log I could see that ScriptEditor was converting my POSIX path into an ‘furl’ (File URL) ! The lightbulb came on and I adjusted my code to do likewise with an NSURL and everything ‘just worked’ as I’d hoped it would. It is odd however – the definition in the scripting def file actually refers to an ‘alias’ an old world MacOS 7 concept that’s pretty much fallen out of use. I expected the path string to be converted correctly, after all I’d already proven that other AppleEvents in other applications (Sketch2 in Leopard is a good test case) that take alias get converted, however it appears as though there’s something more specific in the iTunes case that needs the file URL.

Posted under Development, Leopard

This post was written by awk on October 26, 2007