The other week, I wrote a post about how my Lightroom Classic catalog mysteriously became corrupted (Seriously! 🥴) and how I restored it as well as restored the images and editing I had done since the last catalog backup. You can read about that here. It was not a fun time.
A few days after that problem was analyzed and fixed I discovered another issue. When looking at some older files, the thumbnails in the Library module showed a blank gray preview screen. The upper right corner of the preview showed a black circle with an exclamation point, but not the gray exclamation point that appears if a file is missing. When I tried to open the file a box appeared that said LR could not read the file. What? I then noticed other files in the same folder that were exhibiting the same behavior. What in the world was going on? These files were fine the last time I looked at them and some had been edited and exported for this blog. Now they seemed to have bene corrupted. I checked a few other folders and saw similar files. I then checked the files directly on the hard drive and they were there, but showed 0 bytes of data. Somehow the files lost their contents and only a shell with the file name remained. The XMP files associated with the image files looked fine, however. Another interesting point is that in any given folder, only a few files were corrupted. Files, side by side, showed some corrupted and some just fine and intact. Weird.
Now fast forward a couple of days and about 8 hours worth of troubleshooting and work.
Well, what an “interesting” two days it was. Interesting as in not ‘good’ interesting. As I delved into this the first two questions that arose in my mind were, “What happened?” and “How extensive is it?” The files were fine in the past and somehow lost their entire contents. My next thought was to check my two daily backup drives. Same thing. The backup protocol overwrote the good files with the corrupt files. My next thought was, “Is this a hard disk drive failing issue or some other cause?” Then I wondered just how many files (I have 276,000+ files in my LR catalog) are corrupt and where are they located? Trying to find them would be a daunting task. My day was going downhill fast.
At this point I thought my best option was to consult with an AI chatbot. I use ChatGPT, Claude and Gemini regularly so it was time to get them to help me figure out what was going on and how to fix it. Also, still being a novice with the Apple operating system, I was a bit lost about what I could do to diagnose this. I was a PC user since 1985 and have extensive knowledge, but the MacOS is quite different.
First, I would tackle the potential hard drive being the cause of the corrupt files. So, I queried about the hard drive health. AI felt the hard drive was most likely okay and the corrupt files were an artifact from when I switched from a PC to a Mac earlier this year, reformatted my Windows drive to APFS from EXFAT and copied all my files on to it again. That was the highest probability it gave me. I remember dragging and dropping files from an identical drive because AI said it would be faster than using a program to copy them (it still took almost 18 hours). The downside, I came to realize, is that when you save time you sacrifice the program checking the copied files to make sure they are identical. Dragging and dropping doesn’t. Lesson learned. But, I’m not 100% sure that was the cause. AI’s best guess.
I then asked AI to write a script for the Mac’s Terminal function to identify all 0 kb files on the hard drive, where they are located in subfolders and the dates the files were created. It gave the results to me in a CSV file that I could read it as a spreadsheet. I first ran it as a test. I’m glad I did because it did not produce exactly what I wanted. The next script included all my raw format files as well as JPEGs and TIFFs, but excluded the XMP and some other files. I didn’t want to replace newer XMP files with older ones with older metadata. The result was 1318 files from 2006-2023 that were corrupt in about fifty different folders. Nothing was corrupt after 2023. At least I knew.
I then pulled out an old ‘monthly’ backup hard drive which I took out of service in December of 2024. I checked the image files, specifically several of the corrupted ones and all files were still intact. At least I now had hope that I could replace the bad files with these good ones.
That said, I didn’t want to have to manually go through the folders, find the bad files and then overwrite them one or two at a time so I asked AI to write a script to now replace all the 0 kb files on the current hard drive with the same files from the old backup hard drive. But before replacing them, again, I wanted to make some test runs to ensure I would get the results I needed. It turned out that the script had to be revised several times. After several versions of modifications and a successful test runs I ran the full script. It worked perfectly. All the corrupted files were replaced with good copies. Except…
LR still wouldn’t recognize the replaced files as valid files. They still showed the gray preview screen and had the black circle and exclamation point. After many, many questions and suggestions to try (all failed) both AI and I could not figure out why. We still didn’t know if this was now a LR problem, a file problem or a metadata problem. I double checked the files sizes. The files sizes from the old backup drive and the new copies were exact. AI suggested to try to open them in Photoshop (PS). So, I tried PS and PS wouldn’t recognize them either. However, I could open them successfully independently so I knew the files in and of themselves were fine. AI then suggested about five or six other things to try, including addressing metadata, synchronization and other things of that nature, wrote scripts for each and none of them worked. I then wanted to try something AI didn’t suggest. What I discovered was that if I again replaced files by dragging and dropping from the old backup drive to my current drive, all was good. LR was good to go with them. LR fully recognized them and the edits were intact. Why the difference?
To make this long story shorter, I started to use the spreadsheet I created to manually identify the bad files then drag and drop to replace them. It was just too cumbersome as the files were in about 50 folders. Back to AI which gave me a couple more scripts to try to resolve this issue. After trying a couple the third one almost worked perfectly and allowed LR to recognize the replaced files as it should. But I found there were still a few, scattered about, that were not fixed. The vast majority of the files are now fine and fully recognized by LR. I estimate 95% have been successfully restored.
I decided to stop there and my plan is that when I discover one of the bad files, I’ll connect the old hard drive and replace it. Trying to get to a 100% fix was not worth the extra effort and aggravation. The remaining files are all several years old and not ones I would probably be using any time soon. We all know that getting to 100% takes a lot more time, cost and effort than getting to 95%. The cost/benefit has to be considered in this case. I think there may be less than 30 files that are still not showing correctly.
All in all, this was a real trial of patience. Everything that took place consumed about 8 hours of time.
There is one aspect of my past photography technique to note that sort of mitigated the potential loss of the files. For years, I had the habit, when possible, of making two to three exposures in a quick burst of every scene. I started that when shooting film as a way to protect against a negative (or 35mm slide) being accidentally damaged. Once it was, the negative was unusable. In the digital era and as I have gotten older, that technique helped with image sharpness as the second and third exposures never showed any minute camera motion blur from the act of pressing the shutter. The upshot of this technique is now I typically have three digital files of the same subject as a safety net for this kind of issue. Many of the corrupt files were one of three duplicates. However, many weren’t. So there’s that. Additionally, many were edited and exported and used in this blog. I could have lost a lot of finished images. But having duplicate files is a nice safety net.
For now, I’ll keep the old backup drive handy and as I stumble across any files that will not show thumbnails in LR, I’ll replace them as needed. Now, I have to decide whether or not to cheat fate and replace the hard drive just in case that was the cause. I’m going to run some additional checks on the drive to ensure it doesn’t have sectors going bad. Even if its health looks good I may replace it anyway just so I don’t worry about it. As I mentioned, the last two days have not been great.
Lesson learned: When copying or backing up files, ensure the software has a function that checks the integrity of the newly copied files. Second, it doesn’t hurt to make duplicate digital files in case one becomes corrupt.
Thanks for looking. Enjoy!
Dennis A. Mook
All content on this blog is © 2013-2026 Dennis A. Mook. All Rights Reserved. Feel free to point to this blog from your website with full attribution. Permission may be granted for commercial use. Please contact Mr. Mook to discuss permission to reproduce the blog posts and/or images.
I've found drag and drop to be unreliable over the years when it comes to large amounts of data. Like you I had corrupted files, not a lot, but any is too many. For a very long time I've relied on Carbon Copy Cloner from Bombich.com to copy data when I migrate to newer drives. It does a checksum on each file. It takes a long time. But not my time, as it works day and night while I do other stuff. Highly recommended!
ReplyDeleteMike, thanks for your comment. I do use CCC but didn’t use it for the initial migration. I have a nightly backup protocol designated to two hard drives and have Safety Net turned on for each. I’m hoping that takes care of any issues. I also need to employ Time Machine for the operating system. Procrastination is an ugly disease! Lol. ~Dennis
Delete