Why so long for "Ignoring" /Library?

[macmath]

Hello. First of all, thank you so much for SuperDuper!

I've searched here for similar issues and haven't found one quite like this, so I'm going to bother you.

I ran a "Copy Different files..." on a few directories in the home directory. I believe I had it set correctly because it did exactly what I asked. I watched the log, and it was very fast except for with /Library. Below is an excerpt of that log. The whole task took 43 minutes, but for some reason /Library took 32 of those minutes, even though it was completely skipped. I know that it sorts through the files anyway, but /Developer is somewhat larger than /Library and took only a little over a minute.

I've read here about the 'floating file' issue, and there are some files in /Library which belong to a user besides root, but would that matter when the files are to be skipped?

Thank you very much for your time.
Ed

|06:50:09 AM|Info| Ignoring /Users
|06:51:04 AM|Info| Copying /Users/haar/bin
|06:51:04 AM|Info| Copying /Users/haar/Desktop
|06:51:14 AM|Info| Copying /Users/haar/Documents/Current
|06:51:14 AM|Info| Copying /Users/haar/Documents/Hidden
|06:52:14 AM|Info| Ignoring /.Spotlight-V100
|06:52:22 AM|Info| Ignoring /.Trashes
|06:52:22 AM|Info| Ignoring /.vol
|06:52:22 AM|Info| Ignoring /Applications
|06:53:47 AM|Info| Ignoring /automount
|06:53:47 AM|Info| Ignoring /bin
|06:53:47 AM|Info| Ignoring /cores
|06:53:47 AM|Info| Ignoring /Trash
|06:53:47 AM|Info| Ignoring /Network
|06:53:47 AM|Info| Ignoring /Desktop Folder
|06:53:47 AM|Info| Ignoring /dev
|06:53:47 AM|Info| Ignoring /Developer
|06:54:55 AM|Info| Ignoring /Documents
|06:55:19 AM|Info| Ignoring /System
|07:00:29 AM|Info| Ignoring /Images
|07:00:29 AM|Info| Ignoring /Library
|07:32:09 AM|Info| Ignoring /lost+found

[dnanian]

32 minutes is a very long time to ignore that folder. My guess (and it can only be that) is that the directory might be stored in weak sectors of the hard disk, and stepping through those files (the whole tree is walked) was delayed by the speed of those reads (which might be retrying)...

[macmath]

Thank you for the response, as well as the speediness of it.

So, if that's the problem, I'm guessing that there is no way to address it short of cloning to another drive and re-cloning back (basically a defragmenting). I'd feel safer using SuperDuper! for defragmenting than a defragmenter.

If some day I decide to do that, I'll write back and let you know if that fixed it.

[dnanian]

Well, I don't mean the drive is fragmented. Rather, I think it's failing, or might be. Be careful!

[macmath]

Originally Posted by dnanian

Well, I don't mean the drive is fragmented. Rather, I think it's failing, or might be. Be careful!

Yikes! Then I'll back up doubly-often to my external firewire drive. My data is duplicated on my office Mac, but my wife's is not.

I'll let you know if the drive dies one of these days. Thanks for the warning.

Thanks again for the support. I typically read the manuals and forums before I ask, but it is really nice to have support there when those don't suffice.

[dnanian]

Let me also suggest that you download and install a copy of SMART Reporter (free, from VT). That'll give you some warning (hopefully) before failure.

[sjk]

I suggest also monitoring your console log for "disk i/o error" messages, which is generally a good idea even when you're not suspected a drive problem. Those were an indication of bad blocks on my iMac's internal drive last December and I eventually had the drive replaced. SMARTReporter never reported a problem with it.

[macmath]

Hello.

I think now that this could be a FireWire problem or a problem with the disk in the Firewire enclosure (I'm about to check that out now). Twice now (once with SD! 2.0 yesterday and once with the previous version) everything has hung at some point. I successfully told SD! to 'Cancel' (I think) but I couldn't force quit it. The Finder wouldn't respond either. Finally I disconnected the FireWire cable and everything came to life. Here are a few lines from the system.log. Console.log did not show anything different.

At any rate, I'm convinced that it is not SuperDuper!'s fault.

Nov 23 18:56:34 haar KernelEventAgent[45]: tid 00000000 received unknown event (256)
Nov 23 18:56:35 haar KernelEventAgent[45]: tid 00000000 received unknown event (256)
Nov 23 19:14:47 haar kernel[0]: disk2s10: I/O error.
Nov 23 19:15:17 haar kernel[0]: disk2s10: I/O error.

Thanks for SD! 2!!

[dnanian]

That definitely looks to be a problem with the FW drive, macmath. (BTW, there was no need to delete messages...)

Try erasing and zeroing the FW drive (both free and data space) to see if that helps. If not, make sure you simplify the bus as much as you can -- iSights are known to cause problems in some situations, if you've got one.

[macmath]

It sure was a FW drive issue. I later had the same sort of hang with another utility which I was using to search for bad blocks: unplugging the FW cable brought everything around again. I tried again and at about the same region (block 9 hundred and some thousand or so) it happened again.

Luckily I was able to use Disk Utility with no hangs to zero the drive. After that, I was able to make a full clone with SuperDuper! with no trouble. I need to be on the lookout for a replacement drive!!

You don't need to answer. I just thought I'd report back so that everyone would know that SuperDuper! was fully in the clear on this issue, as it happened with another utility that had to access a broad set of blocks on the drive.

[dnanian]

Yes, definitely get a new drive. Once they start failing like that, it means they've been failing (and transparently remapping sectors) for a long time. It's a good idea to replace the drive, since zeroing will restore the remap allocation (and get rid of currently bad sectors), but certainly doesn't guarantee a long-term fix.