$%*&(@

[spacebug]

Okay, Mac geeks.


My main task while my co-worker was on vacation was to get her computer to stop doing weird things- mostly lots of freezing up, lots of the mouse freezing for a few seconds. She doesn't work with eight million programs open. We ran disk warrior a few weeks ago and it didn't find any big problems, nor did it fix anything, so the next step was backing it all up, and doing a wipe and reinstall. We're stuck in OS 9.2 until the other coworker gets a new 'puter.
For some reason, our regular retrospect backups aren't working, saying the volume is too large to back up. I don't get that, since the firewire drive we use for the backup has almost 70 gigs free, but whatever.
Yesterday I downloaded Silverkeeper to back it up instead, and thought I'd put the copy on one of our servers. Unfortunately, that doesn't work, 'cause her Mac HD is 7.1 gigs, and the servers have under 5g of room.

So I took the firewire drive from the retrospect system (it's an external hot-swap thingie), with its glorious 69 free gigs, and plugged it straight into K's emac to do a backup that way. The backup started and I left work feeling oh-so clever. This morning, it says the backup is incomplete because the volume is full.
HOW THE HELL DOES 7 gigs become over 70 overnight? What is going wrong? What should I do now?


She comes back on Tuesday, and I will feel like a total asshole if I'm not any farther along with this.

Comments

[magicmarmot.livejournal.com]

Sounds an awful lot like a corrupt file, like the actual file length and the reported length don't match. That could concievably be a copy protection scheme for one of the applications, but it might just be a hosed drive.

Not much help beyond that, I'm afraid.

[coprock.livejournal.com]

I have a couple rough ideas.

1. Maybe there are a ridiculous number of small files on the coworker's computer and they can't fit on the larger hard drive with larger block sizes. (With a larger allocation block size more space is wasted and with enough files it might be possible for a larger drive to hold less than a smaller drive maybe.)
2. Maybe there are some aliases on the coworker's computer that point to somewhere else on the drive (perhaps a recursive relationship) or point to another remote volume. When the backup programs attempt to copy everything they follow the aliases and either end up in an infinite loop or try to get data off of a remote server that adds up to more than 70 gigs.
3. Since we're back in OS 9, are there any strange or especially out of date extensions installed on the computer that might be conflicting with each other?
4. Could the eMac running OS 9 see the full 70gigs of free space on the external drive or did it see less than that?

[dangerdhotrod.livejournal.com]

i am new to the whole mac thing - but coprock's #2 idea seems like a winner to me!

[burnunit.livejournal.com]

One added question, is the backup you were doing a straight drag-drop copy, or a software-managed thing like a retrospect backup to a special retrospect file?

My studied opinion is that coprock seems to be on to something with #2. so...
I'd be interested to see what happens when you do a drag n drop into a directory on the external, one folder at a time. It'll be slower, but not as slow as "overnight+failure". Then you'll see which directory it is that's bogging it down. Since you'll be doing a complete format and reinstall, it's not so important to get "invisible" files, so a straight copy should be ok (most of those invisible files will be put there by the system and the install discs anyway.

BTW, when you do reboot and reformat, disconnect that external firewire before you do the system reinstall. I've had lots of trouble with external firewire devices when doing installs.

[spacebug.livejournal.com]

S4 saw this from work and called me about it. This is exactly what the mac genius there suggested.