David G said:
I am working on it. Will post as soon as I have an answer
I had the same problem. It is being fixed. I would send a link to his site but sm not permitted as I am a newbie but here is a precis of where we stand
UPDATE 14 April 2012: There is an issue with update 2.0.4 of The Vault. I am looking into this.
From what I can see the issue is being caused by the following combination of events:
1) Update 2.0.4 enables iTunes Document sharing and therefore has to move The Vault's database to a different folder.
2) Apple demanded that in update 2.0.4 I changed the App's name from "theVault" to "The Vault" to reflect its title in the AppStore.
It appears that this simultaneous combination of events results in partial corruption of theVault's database, causing the app to crash when it starts.
Nevertheless, this should not have happened.
I am doing everything I can to get The Vault up and running again.
I will update my progress here.
UPDATE 15 April 2012 12.44h : May be able to fix database corruption too!
Continued to work on this today, as described above a new version is ready to be submitted that will:
a) allow non-updated 2.0.3 users to update to 2.0.5.
b) allow users who have SecureBackup Bundles, to restore their Vault's contents
and c) possibly fix database corruption!
I succeeded in reconstructing the corrupted sqlite3 headers on two test devices.
Now testing how well the fix holds under different circumstances
Q: What does this mean?
A: If you do *not* have a recent SecureBackup Bundle to restore to: please do nothing and wait for the updated version.
If you delete the app, or unsuccessfully attempt to restore yourself, you may delete or modify the database that The Vault may be able to fix.
Q: How will we know if it worked.
A: If it works, it works, The Vault will just run normally, and your data will be there.
Q: So how could all this happen?
A: From what I see the following happened: when users updated to 2.0.4, iOS changed the name of the application from "theVault" to "The Vault".
At the same time, the app moved the database to another location to allow for iTunes Document sharing. This should not be a problem, however in the process two file handles appeared to have been mixed up by the operating system: output that the app was writing to the Debug Log in fact was written to the SQLite database, overwriting its header.
This is why the app started fine once, then on next start up encountered the now corrupted database and crashed.
Q: How could you possible recover lost data?
A: I cannot, but no data was ever lost.
Only the database header was overwritten, your data was untouched, but unreachable.
What update 2.0.5 attempts to do is reconstruct the SQLite header.
There is much more but this is where we are at
Update 15 April 2012 16.25h: About to submit - a note on chances of success
Will submit v2.0.5 to Apple tonight.
What are the chances of success for those with corrupted database headers?
In general if a CoreData sqlite database gets corrupted, you are lost.
So what I am doing here, reconstructing the database header outside of the control of CoreData.... it's difficult.
However, if it works, it works: if Core Data accepts control over the reconstructed database everything is fine.
I can reconstruct the bytes from offset 0 to 100 of the SQLite header.
Then however follow 24 bytes in Apple's undocumented proprietary format that are very hard to predict.
The fix now works on all my devices, but I expect these 24 bytes may give people trouble.
Without more information, this is all I can do.
Update 16 April 2012 16.26h: Update has been submitted
Update v2.0.5 has indeed been submitted to Apple last night.
Please do not email me when it will be released - only Apple knows.
I will update this website as soon as I am notified the update will be released.
Thank you for your patience.
Update 16 April 2012 19.10h: Apple has granted an expedited review
Apple just notified me that as a one-time exception an expedited review of The Vault has been granted.
I have my fingers crossed.
Mike