If you are referring to the plist files in the Aperture library bear in mind that Apple states that the Aperture library needs to be on a locally mounted OS X formatted volume. See Aperture: Use locally mounted Mac OS X Extended volumes for your Aperture library
They are all locally mounted - I don't what wouild have given you the impression they are not.
and I've been using them for years. I have the Aperture Library as well as ref'd and non-ref'd masters all on external drives.
The working library is on a 6T LaCie OSX HFS journaled drive that is backed up to a RAID.
So, the corrupt files are coming from the 6T Aperture Library.
I don't what wouild have given you the impression they are not.
Reread your post. You're talking about your RAID going down and how you think you've traced the problem to corrupted plist files in the Aperture library. Why would I not think you were running the libraries off the raid
Given the errors you are seeing with DiskWarrior I'm surprised to hear that the LaCie tech support think this is what is bringing down their RAID. A malformed file shouldn't do that. The RAID should not be caring what is in one of these plist files.
But be that as it may, if the only files that you think are causing the problem are these types of plist files, in Database/History/Changes then it should be safe to delete them.
Fair enough - I can see why you made the connection. The RAID was crashing, the other drives were not. We ( the LaCie techs and I ) made the deduction that since it was corruption and not hardware, and the RAID was a backup, the corruption was scoming from somewhere else ( mainly the drives it was backing up ) - that was the logic. I ran a scan and found the very same problem with the Aperture .plists. on the drives. So, in the end, the stand-alone drives were functioning with the corrupted data - the RAID ( 05 Mode ) would not.
My question is manyfold /
- why would this happen - if I don't understand why this is happening, I cant really fix it.
- LaCie's stance is that it's not a hardwre problem - its corrupt content. I have rewritten the RAID directory structure, but it will just happen again if I dont fix the problem.
- What do the .plists acutally contain and are they sequestial and interdependent ? i.e., if I delte them all from the sparsefile history/changes - will i lose any data ? or is it only the very last .plist that carries all the info ?
To pu tit another way, I have 67 .plist files that are corrupt (have no idea why ) but they go from 1 - 208. The last corrupt playlist is 198 - can I delete everything before 199 and continue ? all the file sizes vary extensively so ....
I can;t answer why DiskWarrior is saying these plist files are corrupt. I don;t have the program so I can;t run it here on a working library to see what DW would report. For all we know its an artifact of DW and not a problem with the plist files at least as far as Aperture is concerned.
I asked before did you try running the Aperture library repair functions on the libraries in question and then run DW to see if there is any change?
I'm not totally convinced the RAID problem is related to this. I still can;t see why a corrupted plist file would cause the RAID drive to fail. Why should the RAID care if there is a value missing from inside a DICT entry in a plist file (as one of the DW errors shows)?
You might have just stumbled on the perfect storm of coincidences. That is the RAID has problems, noting can be found, you dig deep enough and find this.
So I guees the questions are is Aperture having a problem? Does the Aperture library repair do anything for the problem. Finally have you run DW on a libary not on the external drive.
I just checked the DW site and they don;t appear to have a trial version so I can;t try it here. At this point I'm not sure what to tell you. As I wrote previously you can delete those specific plist files without messing up the library. But why it happened or if it will happen again or even if this is your RAID problem I can;t say.
Thanks for the response. Lets try to re-frame this. Let's forget about the RAID, it's just confusing the issue. I have both my AP Library and Referecned Masters on external drives. All those drives are backed up to the RAID. None of the other drives were reporting problems as 'corruption on a single bay drive will not bring it down. It will, however on a RAID 5, make it inoperable. The point being - the corrupted data came from the other drives - not the RAID.
I don't keep anything related to Aperture on inernal drives. This allows me to wipe my OS if need be.
Dwarrior was the only program I could find ( also reco'd by LaCie ) that would repair the directory structure. I will run the same on all the drives. I would def reco DW for any user with external drives. Most of the times, the problem is Disk Utility and the arcane error, or dir structure it uses. DUtil coulnt even access my drive.
You hadn't mentioned the Aperture Library rebuild, and it's an interesting thought. I don't know why I hadn't thought of it either. If it happens again, I'll give it a go.
I duplicated my AP Library file, deleted all the corrupted files, and running backups off the new one. I will give it a week or so and see how it behaves and then clear out all the old stuff, but for now it seems to be running fine.
This whole scare (second time, really) is forcing me to actually have a 'version drive' with all my finished portfilio stuff on it. Once you open that SPARSE bundle it gets pretty busy - no wonder things just tweek.
I have two seperate Aperture Libraries, one on my local drive and another on a Firewire connected external drive. Disk Warrior is reporting corrupted plist files on both drives under the Aperture sub-folders ....History/Changes.
As far as I can tell this is common, and anybody running a utility such as DW or Tech Tool will get these warnings. Clearly there is something about this specific plist file format that causes utilities to see them as corrupt.
I don't believe they cause a problem, and deleting them wont stop new ones from being created. Best to ignore I think.
I'm a bit late here, but as Gary has resurrected it I thought I'd just add 2cts.
I'm pretty sure these are just dumps of the history log in Apertures database that are getting saved, probably so the actual history log can be kept small rather than grow indefinately.
The latest file seems to get reused until it reaches some abitary size (about 20MB on my system) and then the next one starts. This is likely the cause of the corruption, where it gets opened and not closed properly, perhaps due to an Aperture crash or a hang followed by a Force Quit. I suppose there is a tiny chance the corruption could be due to badly escaped data getting seen as EOF but really can't see that being the case.
However, the real concern for me is that something like this could take the Drobo down. That makes it sound like the Drobo is a hack. Perhaps that explains why there seem to be so many issues about it.
If it was me, and the corrupt plist files are the issue, I'd be looking to replace the Drobo ASAP. In the meantime I'd have no issue deleting these plist files to temporarily circumvent the issue.
So... I had similar issue. With only one of my 5 Aperture databases. It is the one I've been having problems with for a long time (year).
I've been doing repairs/maint and sorting out drive issues and noticed a few things.
I have 254 of these change/history files ranging in size from 3kb to 20+mb. ranging over 2011-14 dates. 30 are shown as problematic by TechTool7.
A couple of comments re things mentioned in earlier posts:
These files do seem to get edited on an ongoing basis by Aperture as a few modified dates are from today (note I've been forcing a lot of old files to rebuild)
The data in them is just an xml change log and the errors seem to be bad writes, ie an entry that is truncated and a new one started on top of it.
The errors that I get are all xml tag balance errors, or miss formed tags. This is a really 'dumb' error report, ie it is just reporting formatting errors.
I went through and repaired (removed entire screwed up change entry) a few of the reported errors, and have seen no downside, but not sure if I've really hit the changes.
Anyway, I'm moving away from Aperture because of it's unreliability.
Also, I would be careful with database rebuilds... they recover a lot of material that you may have thrown away purposefully and create an 'accounting' nightmare. Use them sparingly... Yet another reason I'm only using Aperture for family stuff going forward. Ouch on all the org word that went into it over these last years, but I guess just sunken cost.
Hope it helps to future people with this issue. Seems like the topic is pretty dead.