Corrupt..or not?

EagleFiler
1

Hi Michael and forum members-

I’ve been testing Eaglefiler since just after Christmas, and loving it so far. I’m enjoying using the software, and I’ve also been very impressed at the breadth and helpfulness of the information in the forum.

But last night I got an alarming message warning me files were corrupted. Today I researched in this forum and the manual, which led me to find the Eaglefiler Log (I’ll excerpt below) which did indicate some corruption. I also discovered Verify, and when I tried it on all the records in the 2 libraries I’ve created so far, all but one file tested OK (i.e. failures were 0 except for that one). Oddly, that file is not in the library listed in the log as having a problem; it’s in the other one.

I’m not terribly technically savvy, so please forgive any inadvertent misuse of terms. What I’d like to know is the following:

1 - Do I have a problem with corrupted files, or if they test out okay with Verify have they somehow repaired themselves? (and I don’t need to worry about it).

2 - Is it possible to tell from the log how they became corrupted, and if so, was it something I did (and can avoid in future)?

The library is still very small–I could either start from scratch to rebuild it, or could follow the directions in the 10/08 discussion about corrupted files from davet (which was VERY informative)–but obviously I’m concerned about how quickly and easily I managed to screw it up. I’d very much appreciate your thoughts on how I could prevent doing this in future, because I really like the way Eaglefiler works and could quickly come to depend on it.

Thank you in advance for your help.
Dinah

I’m running 10.4.11 on an eMac. Eaglefiler is on the main computer, but the libraries are both on an external hard drive. So far, I have only received the one alert about corruption. Eaglefiler seems to be running fine, and closes and reopens normally.

Here is yesterday’s activity from the Log. There are some previous entries referring to corrupt files from earlier in the week, but this was the first time I got an actual error message on screen:

2009-01-03 23:35:34,533 - documents.pyc:81 willPresentError: <NSError Domain=com.c-command.EagleFiler Code=0 UserInfo={
NSLocalizedDescription = “Could Not Save Library”;
NSLocalizedRecoverySuggestion = "error: NSInternalInconsistencyException - Fatal error. The database at /Volumes/External HD/Library-First and General/Library-First and General.eflibrary/Contents.db is corrupted. SQLite error code:1

com.c-command.EagleFiler: 0";
traceback = “Traceback (most recent call last):
File “wash/documents.pyc”, line 171, in writeSafelyToURL_ofType_forSaveOperation_error_
File “wash/library.pyc”, line 940, in save
File “wash/storage.pyc”, line 909, in save
File “wash/storage.pyc”, line 659, in propagateChangesToManagedObjects
error: NSInternalInconsistencyException - Fatal error. The database at /Volumes/External HD/Library-First and General/Library-First and General.eflibrary/Contents.db is corrupted. SQLite error code:1”;
}>
2009-01-04 20:28:42,050 - appcontroller.pyc:139 Launched EagleFiler 1.4.3 (on Mac OS X 10.4.11) at 2009-01-04 20:28:42 -0800

2

The Verify command is for checking the contents of the files in the library to see if they are damaged. If Verify says that the files are fine, you can be sure that they are. (If it says that a file’s checksum doesn’t match, maybe it was damaged or maybe you edited it without EagleFiler’s knowledge.)

The error in the log is actually something entirely different. It’s saying that Contents.db, the database file that EagleFiler uses to track the files in the library, is damaged. This is good news, actually, because EagleFiler automatically backs up the information in that file. There is a simple procedure to have EagleFiler reconstruct it. After doing this you can do a Verify to make sure that the files in the library are OK.

It’s rare for the database to be damaged because it’s designed to be impervious even to crashes. It’s very unlikely that the damage is due to anything that you did. There’s no way to tell what happened, though. Most likely the damage was caused by a disk error, either because the disk’s catalog is damaged (causing it to lose track of where each file is stored and possibly overwrite the contents of one file with another) or because the drive itself has a hardware problem.

It’s dangerous to use a bad drive because you never know what problems it might cause. Verification only works for EagleFiler’s files, and it can only detect problems after the fact. I suggest that you boot from your Mac OS X DVD and run a Disk Utility repair on your hard disk. If possible, I’d also check it with a more thorough utility such as DiskWarrior or Drive Genius.

3

Thank you
Thanks for your reassuring, rapid and very clear explanation. Also thought-provoking. Let me do some checking and see what happens. I had been having a problem where the computer would lose track of the hard drive and it would vanish off my desktop–I thought I’d solved it by repairing permissions, since it stopped vanishing, but maybe that wasn’t quite enough of a solution.

Again, thanks–
Dinah

4

That doesn’t sound to me like a problem that would be caused by bad permissions.

5

Oh Michael, that really begs the question, doesn’t it? I’ll certainly welcome any speculation on what kind of problems I SHOULD be looking for, although I know that’s asking a bit much… I’d optimistically assumed that since running permissions solved the problem, that was good enough. The other probably related phenomenon is that I occasionally, and as far as I can tell, randomly, get the complaint that I didn’t properly eject a device. You’ve got me sufficiently alarmed that I’m definitely going to check into a disk utility program–no point backing up on a hard drive that’s going to die on me.

Meanwhile maybe I’ll just try putting everything into my (just purchased) copy of EagleFiler & backing it up on MobileMe.

Seriously, thanks a lot for your help–I’ll keep trying to figure stuff out through the manual and the info on this forum, but it’s incredibly reassuring to know you’re there to answer questions when it gets too baffling.

Dinah

6

This is not my area of expertise, and I’m just speculating; it just doesn’t seem logical that a permissions problem would make a drive disappear. I had a similar problem a few years ago (also with the error message about not properly ejecting the device), and the problem ended up being the drive’s enclosure. Every once in a while the drive wouldn’t get enough power, so it would turn off, and the OS would notice that it was no longer connected and complain. (The enclosure was plugged into a UPS, so I know the power going into it was good.) This problem was not detectable with disk repair software because, when the power was good, the drive operated normally. I took the drive out of its enclosure, put it in a new one, and it’s still operating perfectly to this day.

7

Bingo

I’m sitting here in my 1915 house with the original knob and tube wiring thinking that you may have hit the nail on the head. This would also explain the apparent randomity of the problem–if, for instance, it was triggered by heavy power tool use on the weekend (the kind that results in a visible dimming of the lights), as opposed to anything I was (or was not) doing on the computer. Definitely another area to investigate. Thanks.