Copy link to clipboard
Copied
This problem is noticed by me recently, and I find that all the backup catalogs created by Lightroom Classic CC (“Lightroom”) after 14 January 2018 was corrupted (as Lightroom said). The most recent backup catalog which I can use is the one created on 14 January 2018.
However, Lightroom is working normally and seems no problem at all. I can edit photos as usual. I have set Lightroom to back up the catalog every time when I quit Lightroom, and it seems everything alright. However, when I try to use the backup catalog, it fails. Lightroom said they are corrupted. I don't know why.
Last night, I have done an experiment. I backed up my catalog as usual when I quitted Lightroom. Immediately after I quitted Lightroom, I unzipped the backup catalog and copied the catalog to the default folder which Lightroom uses. I reran Lightroom and Lightroom said my catalog is corrupted. This copy was just created by Lightroom when I quitted Lightroom last time. I then removed the backup catalog and putted back the current catalog in default folder. Lightroom just works fine. It seems that Lightroom does not correctly back up the catalog. Very strange!
Is there any method to solve the above problem? Please help.
Copy link to clipboard
Copied
Sorry to hear that one more user experienced the same problem. Adobe provides no support to it users, but only leaves a forum for users to discuss between them, too bad. If you continue to use Lightroom, the only safe way to back up your catalogue is manual backup.
Copy link to clipboard
Copied
Thanks for the reply, Henry. You are correct about the backup issue, and I now backup manually. Too bad we can't get Adobe to address this issue.
I have had three interactions with Adobe about program problems this week -- the latest was about an Assertion Error that flat out prevented LR from opening. Assertion error is a programming level code that dumps the program, causing it to crash, if it encounters an issue that would be a problem to the program. It is used by programmers to debug programs. The program should not be released with such potential stops in it, as it leaves the customer without a clue about what the problem was that stopped the program and how to resolve it. The Adobe site had a solution that obviously came from a previous "assertion error" issue, and my assertion error was caused by a different line of code -- so their solution was therefore useless. It was only by chance -- and most of a wasted work day -- that I got my program to work again.
Adobe does not have any kind of effective Customer Support -- except around places where we, as customers, give them money. That's a lousy business model, but oh well -- that's America for you these days. Businesses do not concern themselves with their customer base, but rather with their investment base. If the program works well enough so people buy it, that's all they need: their investors make their money. At its heart, that's why Customer Care is not a priority. Adobe is not the only company in this position, but America will not be truly great again until we reverse our head space about how businesses should be run.
Copy link to clipboard
Copied
An interesting problem! I have just found one backup zip file that opens in LR but won't run; one that opens and runs but can't find a few thousand files that are present in the others, and several backup zip files that open and run without any problem. All made in March with 7.2, and opened with Directory Opus - a file manager.
Perhaps this shows us why Adobe were adamant for several years that they would not compress catalog backup files - we had to compress them manually if we wanted to. Eventually Adobe gave in and started compressing them and this is the first time I have found any problem with the compressed backup files. But it is obviously an intermittent problem, only one or two of mine won't open in LR. The rest made only a few days apart are OK.
What does Adobe use to compress the files? Does it use the OS zipper/unzipper? Is this related to OS updates? Does it occur on Windows and Macs?
Bob Frost
Copy link to clipboard
Copied
When I to open a LR backup zip file with the Win10 extractor, LR will not open the extracted file. But when I open it with my Directory Opus unzipper (autoextract) by just double-clicking on the zip file, then it opens and is fine in LR 7.2 Have you all tried some diiferent ways of unzipping the file?
Bob Frost
Copy link to clipboard
Copied
Just realised you don't need to use an unzipper! Just open LR and tell it to open another catalog and point it to the backup file. It opens it!!
Bob Frost
Copy link to clipboard
Copied
Back again! Using LR to open the backup catalogs, I just found one that even LR would not open; it said it was corrupted. BUT it offered to repair the catalog, and it did! So all is not lost it seems if your backup is corrupted.
However, until this is finally sorted, I'm simply copying my catalog files to the backup dir without compressing. Adobe might have been right in the first place.
Bob Frost.
Copy link to clipboard
Copied
https://forums.adobe.com/people/bob+frost wrote
Back again! Using LR to open the backup catalogs, I just found one that even LR would not open; it said it was corrupted. BUT it offered to repair the catalog, and it did! So all is not lost it seems if your backup is corrupted.
However, until this is finally sorted, I'm simply copying my catalog files to the backup dir without compressing. Adobe might have been right in the first place.
Bob Frost.
Within LR, Adobe provides options for (a) testing a catalog integrity; (b) backing up a catalog, with and without integrity testing. The backup is compressed, but that's Adobe's choice, not mine. For some users (quite a few have chimed in) these options are fatally broken. In particular (in my case, and likewise for others):
These flaws resulted in my having to completely rebuild my catalog from my last pre-Classic backup (six months old!). This cost me 2 weeks full time.
I'm sorry, but Adobe was certainly not "right in the first place".
FYI, Adobe did offer to try and repair my catalog, and they sent me back one that they said was repaired. It wasn't (assertion failed on startup), and they ended up admitting it couldn't be fixed.
js
Copy link to clipboard
Copied
"I'm sorry, but Adobe was certainly not "right in the first place". "
....................................................................................
By that comment I meant that Adobe's decision for many years NOT to compress catalog backups because it was too unreliable, was perhaps the correct decision.
I think that the golden rule for compression/uncompression is to use the same program/utility for both the compression and the uncompression. Programs/utilities are not always compatible even with 'standard' zip files.
"The integrity test run as part of backup is useless - it seems to have zero effect, and always passes a corrupt catalog. "
...............................................................................................................................................................................................
How do you know the catalog was corrupt before you compressed it and backed it up?
I ran the integrity test as part of opening one backup in LR (it is there as an option), and it found the catalog was corrupted and offered to repair it which it did. This was the only one that was corrupt; the other opened fine.
Bob Frost
Copy link to clipboard
Copied
I think that the golden rule for compression/uncompression is to use the same program/utility for both the compression and the uncompression. Programs/utilities are not always compatible even with 'standard' zip files.
Unfortunately, I think you're right. But in my view that doesn't excuse Adobe. If LR produces what appears to be a standard Windows zip file, then users should be able to count on standard windows zip extraction commands to work seamlessly and correctly.
I guess the platinum rule is to eschew compression entirely!
"The integrity test run as part of backup is useless - it seems to have zero effect, and always passes a corrupt catalog. "
.......................................................................................... .......................................................................................... ...........
How do you know the catalog was corrupt before you compressed it and backed it up?
In one case, I had a catalog that I knew was corrupt - LR would open it, but consistently crash later (often in reproducible ways). If I opened that catalog and then exited with backup+integrity, the backup ran to completion without complaining. I had a similar catalog that was judged corrupt by the integrity test run on startup. But I could open that catalog directly (without the test) and then exit/backup, again with integrity testing. And, as before, the backup ran to completion without complaining.
I ran the integrity test as part of opening one backup in LR (it is there as an option), and it found the catalog was corrupted and offered to repair it which it did. This was the only one that was corrupt; the other opened fine.
Yes, in some cases LR can repair catalogs that fail the integrity test. But that's not true in general - in other cases, the integrity test can detect corrupt catalogs but be unable to repair them. And there are still other cases, as mentioned, of catalogs that are corrupt but in fact pass the integrity test.
Copy link to clipboard
Copied
"I guess the platinum rule is to eschew compression entirely!"
.....................................................................................................
Yes. If they put a checkbox in the backup dialog to choose compression or not, that would avoid the problem. Before Adobe added compression, I used to compress and uncompress my LR backups with 7Zip. No problems.
But compressing with LR and uncompressing with some other program/utility is not guaranteed to work, and I doubt it ever will be. Reading Wikipedia's article on zip compression shows why this is so:-
"The .ZIP File Format Specification documents the following compression methods: Store (no compression), Shrink, Reduce (levels 1-4), Implode, Deflate, Deflate64, bzip2, LZMA (EFS), WavPack, and PPMd. The most commonly used compression method is DEFLATE, which is described in IETF RFC 1951."
Bob Frost
Copy link to clipboard
Copied
This is a most fascinating conversation, and it will be fun to see how this works out over the course of the next few years. There is clearly a problem of some kind with backup as Adobe has configured it, and at some point I suspect they will find a solution that works. But what is clear now is that many, many more people are having difficulties with the backup process in the program than appears on the surface. Adobe does not have have it right yet, and until they do get it right we should do manual backups even if we still use their backup system.
I think LR (and PS) are very complex programs, and I have a great deal of respect for the programmers who create them. They are great programs. But (sorry, there is a "but") there are lots of other complex computer programs that have processes that make them work more smoothly, and that iron out difficulties as they arise. This one (and many others that I have found this week through an assertion failure that crashed my program unrecoverably) will be a challenge for the Adobe staff, and I do hope they take on the challenge. After all, it is our creative juices that lie in the balance and I would be very sad to see all the results of my work going up in, well, lost pixels. My creative work is important to me, and I wish I had the feeling that Adobe respected and understood that.
John Whiteside
Copy link to clipboard
Copied
Been dealing with "assertion failed" and corrupt catalogs in LightroomCC for the past week, sometimes I can repair it, sometimes not. This is unacceptable! I just got off a 2hr phone call with Adobe customer support, and all we figured out was that my catalog is corrupt (duh!) and I should check my winzip? I'm tired of losing my hard work and I'm just going to go back to my previous version Lightroom 5.7! I want my money back for my CC subscription!
Copy link to clipboard
Copied
I am a very naive user of all programs generally. It's gotta work period or I am lost in a void. I have no backups. They've disappeared. Reading this thread looks like it's Adobe and not my computer (Mac - High Sierra 10.13.3).
All the above is gobbled gook. I'm just figuring out LR. Panic Attack indeed. Going to have a drink now. Will keep an eye on this thread to read solutions.
Oh - I did do a Time Machine back-up 21 days ago.
Copy link to clipboard
Copied
I have done two test restorations. The one restoration was done to the desktop and I tried to start Lightroom with that catalog on the desktop. Lightroom indicated that the catalog needed to be repaired. There were no other files associated with Lightroom on the desktop. Lightroom repaired the catalog successfully and eventually opened it. The second restoration was placed in the folder with the other files where the original catalog was. That catalog opened without a problem, no repair was needed. Using Lightroom Classic CC 7.2 on Windows 10.
Copy link to clipboard
Copied
Just wanting to add some technical details here. After losing about a month's worth of catalog data, I have realized Lightroom has been saving corrupt backups since February. If I save a backup (with the optimize box checked), then immediately open the backup catalog using a SqLite reader, I see the following slew of errors:
*** in database main ***
Main freelist: free-page count in header is too small
On tree page 104 cell 0: 2nd reference to page 10559
On tree page 104 cell 5: 2nd reference to page 7579
On tree page 104 cell 4: 2nd reference to page 7535
On tree page 104 cell 3: 2nd reference to page 8090
On tree page 104 cell 2: 2nd reference to page 3650
On tree page 104 cell 1: 2nd reference to page 3771
On tree page 104 cell 0: 2nd reference to page 3728
On tree page 321 cell 0: 2nd reference to page 4204
On tree page 321 cell 5: 2nd reference to page 4172
On tree page 321 cell 4: 2nd reference to page 4155
On tree page 321 cell 3: 2nd reference to page 4153
On tree page 321 cell 2: 2nd reference to page 3766
On tree page 321 cell 1: 2nd reference to page 3725
On tree page 321 cell 0: 2nd reference to page 3724
On tree page 320 cell 0: 2nd reference to page 4221
On tree page 320 cell 5: 2nd reference to page 4220
On tree page 320 cell 4: 2nd reference to page 4173
On tree page 320 cell 3: 2nd reference to page 4152
On tree page 320 cell 2: 2nd reference to page 4163
On tree page 320 cell 1: 2nd reference to page 3727
On tree page 320 cell 0: 2nd reference to page 3726
On tree page 105 cell 0: 2nd reference to page 4937
On tree page 105 cell 2: 2nd reference to page 4750
On tree page 105 cell 1: 2nd reference to page 3730
On tree page 105 cell 0: 2nd reference to page 3729
On tree page 80 cell 0: 2nd reference to page 17059
On tree page 80 cell 42: Rowid 461738 out of order
On tree page 11 cell 136: Rowid 463919 out of order
On tree page 11 cell 135: Rowid 462404 out of order
On tree page 10 cell 375: Rowid 464237 out of order
On tree page 10 cell 374: Rowid 463736 out of order
On tree page 17356 cell 8: Rowid 464237 out of order
On tree page 89 cell 0: 2nd reference to page 8217
On tree page 12297 cell 32: Rowid 464252 out of order
On tree page 8158 cell 41: Rowid 463400 out of order
On tree page 21 cell 0: 2nd reference to page 10389
On tree page 21 cell 378: Rowid 460608 out of order
On tree page 3852 cell 9: Rowid 460613 out of order
On tree page 51 cell 321: Rowid 464300 out of order
On tree page 51 cell 320: Rowid 463913 out of order
On tree page 51 cell 320: 2nd reference to page 17087
On tree page 51 cell 47: Rowid 290131 out of order
On tree page 51 cell 46: Rowid 289704 out of order
On tree page 14366 cell 10: Rowid 290551 out of order
On tree page 51 cell 36: Rowid 285599 out of order
On tree page 51 cell 35: Rowid 285203 out of order
On tree page 19299 cell 9: Rowid 285997 out of order
Page 12377 is never used
Page 18330 is never used
When I generate a backup with the optimize box unchecked, I only see the following errors:
*** in database main ***
On tree page 18296 cell 6: Rowid 384 out of order
On tree page 18295 cell 7: Rowid 377 out of order
When I try and open the first (optimized) backup Lightroom immediately encounters an error and must quit. The second (unoptimized) backup is at least functional as far as I can tell. I can still import photos from it, which is my main use case. I'll still be manually copying my catalog periodically until this is resolved.
Running Lightroom 7.2 on Windows 10.
Copy link to clipboard
Copied
Your discovered issue is exactly what I found.
Sent from my iPhone
Copy link to clipboard
Copied
I have just started having the same problems. Mine started with 7.3.1. From reading here, it seems as though the problems were in Windows OS. I am using Mac OS, so it has crossed over. Or maybe it has existed for a while and just now reared its ugly head. Mine started with a LR 7.3.1 backup when it failed the integrity test.
Distraught
Find more inspiration, events, and resources on the new Adobe Community
Explore Now