Stupid Apple

The Gorse Fox has a love/hate relationship with his Mac. Today it is verging on the hate.

For some reason, when GF had to rejig his network to accommodate the new BT hub, the behaviour of the backup routines changed. Some directories wouldn't get created, and the backup programs would confuse source and target. This has led to several weeks of minor fiddling to try and correct the errors. Alas, this has not been wholly successful. It was time for a more radical approach.

The Gorse Fox created a new "share" on his target NAS. This would be the new destination for backups. However, this meant that there were hundreds of gigabytes of data to worry about. No worries, he thought. OSX is UNIX-based. A "move" in UNIX merely means the relocation of an inode pointer between directories. This would take milliseconds.

Oh no it won't. For some reason OSX still performs a copy(*)... which took nearly 24 hours. What's worse, it gives every file a new "last modified" time. Thus when the backups restarted they noticed the huge time difference and decided they needed to overwrite the files with the older version - just to be sure. The NAS device has been rattling away solidly for nearly 48 hours now... but at least the backups seem to be functioning correctly.

Jasper-the-cat, is quite sensibly, staying out of the way.

(*) Purists might tell you that using the "mv" command from the command line will do the trick. GF can inform them that after many, many hours the command fails claiming there are too many files in the filesystem. They may also tell you that holding "cmd" during the drag'n'drop will do a move. GF would counter that whilst the message changes to say it is doing a move... a task that should take milliseconds rand for several hours... and "touched" every file.