Apple Photos App Corrupts Images
Posted4 months agoActive3 months ago
tenderlovemaking.comTechstoryHigh profile
heatednegative
Debate
80/100
Apple PhotosImage CorruptionData Integrity
Key topics
Apple Photos
Image Corruption
Data Integrity
The Apple Photos app corrupts images, particularly when importing from Olympus cameras, sparking a heated discussion about data integrity and Apple's software quality.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
18m
Peak period
100
0-6h
Avg / period
16
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 17, 2025 at 7:07 AM EDT
4 months ago
Step 01 - 02First comment
Sep 17, 2025 at 7:26 AM EDT
18m after posting
Step 02 - 03Peak activity
100 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 21, 2025 at 2:08 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45274277Type: storyLast synced: 11/27/2025, 3:36:14 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://github.com/LANDrop/LANDrop
I used it along with another called Localsend, but the later one gave me a bit of headache and crashed while transferring some large files last time I used it, but still great as an alternative too, and it’s open source as well.
Edit: Actually, you are correct, it seems they did close it! Try localsend instead.
I’ve used Olympus cameras for over a decade. Well, the same camera to be honest, a PEN E-PM2. This has only appeared in the past couple of years.
I haven’t seen it on photos from my Canon EOS 80D yet, but I guess it’s time to change my workflow. And maybe OS.
Though, considering the macOS 26, it’s likely the Photos app.
As far as I can tell:
- 0x7800 bytes were replaced at file offset 0x00aa0000
- 0x2200 bytes were replaced at file offset 0x00aa8000
I can't tell if the replacement data came from a different part of the file, or somewhere totally different. Race condition somewhere sounds plausible.
So some part of the chain with 512 byte buffer size corrupted the data.
It doesn't look like a memory corruption but if this were my computer I'd run the equivalent of memtest86 on it.
It looks like a filing system corruption to me. Running `diskutil info` on the main harddisk and the sd card might be interesting to see if the block sizes match.
Running a disk tester on the sd card and the main disk might be a good idea too. Here is one I wrote: https://github.com/ncw/stressdisk
The visible effect shown could be due to a change as small as a single bit flip. It also could be that large parts of the file got overwritten, or that it partially got zeroed. The exact kind of damage can help pinpoint the cause of the problem.
Yes this argument is a bit unconvincing for me. Not saying Apple photos doesn't corrupt his files, but this is not real proper investigating either.
That said, the article does mention replacing basically all the hardware and still encountering the issue. FWIW, my personal experience with Apple software so far is that the usage expected for Average Joe is well tested and polished. But stepping outside of that, it's "Here be dragons" territory very quickly.
Photos does a lot of extra work on import (merging RAW+JPEG pairs, generating previews, database indexing, optional deletion), so my guess is a concurrency bug where a buffer gets reused or a file handle is closed before the copy finishes.
Rare, nondeterministic corruption fits the profile.
They constantly ask for an example project, even if it's something that is easily demonstrated, simply by running existing Apple software, and creating a project, would be a huge pain.
They also ignore reports. Very rarely, I may get a ping on one of my reports, asking me to verify that it was fixed in some release. Otherwise, there's no sign that they ever even read it.
I usually end up closing my bug reports and feature requests, after a few months, because I'm tired of looking at them.
It's clear that they consider every bug report to be a burden. That's a very strange stance, but then, they are not a typical company.
I guess you can't argue with the results, as they have a market value North of 3 trillion dollars, but that does not make it any less annoying.
I start my first day @ Apple in a few weeks, so I ACK that my opinion might be a little biased here.
(Yes, this came close to killing someone close to me. Fortunately someone else happened to come along to help.)
There were certain photographers and publications, that, if they got upset, all hands were on deck, for even the most innocuous bugs.
Btw I wonder if Apple sends some spoken message to the emergency services or some metadata or just connects the phones and that's it.
Edit: oh and I forgot: my wife got a loud message (that bypassed DND) telling her that her father maybe felt, because she is one of his emergency contacts.
Also, you may not be aware of Car Crash Detection https://support.apple.com/en-us/104959
The Insurance Institute for Highway Safety has done a lot as a private organization to raise standards for automotive safety but the statistics they publish that show that larger vehicles are safer than larger vehicles are frequently wrongly interpreted -- in many of the cases where the large vehicle does better it's not that you die in the smaller vehicle but instead get a broken bone. Once something is seen as "life or death" some people will think they have no choice but to spend another $50,000, spew another 20 tons of carbon pollution, etc.
From https://9to5mac.com/2023/02/03/iphone-crash-detection-critic...
“My whole day is managing crash notifications,” said Trina Dummer, interim director of Summit County’s emergency services, which received 185 such calls in the week from Jan. 13 to Jan. 22. (In winters past, the typical call volume on a busy day was roughly half that.) Ms. Dummer said that the onslaught was threatening to desensitize dispatchers and divert limited resources from true emergencies.
I don't recall there ever being any official language about "squeezing both sides of the phone" to make emergency calls. Doesn't the feature description in Settings explicitly reference which buttons to press?
In case of emergency, use your iPhone to quickly and easily call for help and alert your emergency contacts (provided that cellular service is available). After an emergency call ends, your iPhone alerts your emergency contacts with a text message, unless you choose to cancel. Your iPhone sends your current location (if available) and—for a period of time after you enter SOS mode—your emergency contacts receive updates when your location changes.
Note: If you have iPhone 14 or later (any model), you may be able to contact emergency services through satellite if cell service isn’t available. See Use Emergency SOS via satellite on your iPhone.
Simultaneously press and hold the side button and either volume button until the sliders appear and the countdown on Emergency SOS ends, then release the buttons.
Or you can enable iPhone to start Emergency SOS when you quickly press the side button five times. Go to Settings > Emergency SOS, then turn on Call with 5 Presses.
Even if it's standard among tech giants, you could be the one that makes a new standard! Good luck in your new role, btw.
Wasn't there an xkcd about that scenario...
https://xkcd.com/1739/
I don't think my bank had intended to make passwords optional, and the third-party administrator of their bug bounty program agreed, when creating the report, but once it made it to the bank, it was up to them to decide if it was or was not a bug.
This was financed by equally massive technical debt.
That’s what technical debt is. It’s the cost for moving forward quickly. I’m not sure I understand what you’re trying to state.
You seem to be assuming that the company will eventually pay off the technical debt rather than just continue accumulating it and lowering production quality.
Once you have market power (which means different things for different companies) you can safely feed the tech debt monster just as little as you feel like.
From your description, your experience is quite typical.
I've had pretty good luck reporting bugs to Google (notoriously bad!):
1. provide simple, crystal clear examples that cannot be due to third parties, misconfiguration or user error.
2. show that it's happening to a large number of mainstream users (not niche)
3. show that it breaks critical workflows and has no easy workaround (incl partial workarounds).
4. if you meet #1-3, then wait 6-9 months minimum (more if hard to fix). If not, wait 3-5+ years.
---
Favorite example: in the mid-2000s, I caught google maps confusing suite/apt numbers for street numbers. It got flagged as low priority. So, to get the team's attention, I reproduced the bug on a large Google offices. Six month later, bug fixed.
After that experience, I report everything to Google that breaks my workflow. Like clockwork, the biggies get fixed a couple of quarters later.
---
Want long? Try improving/fixing core issues with the API design of Linux or PostgreSQL: fix times can be measured in decades. Backward compatibility is insufficient - they rightfully worry about libraries and tools adopting the new APIs and then breaking legacy systems that cannot be upgraded even for mission-critical security issues.
---
NOTE: OP bug feels P0 and the better strategy is either mass media (incl HN) or networking to someone inside the company. I've hit those too over the years and can usually find someone at the company to send directly.
They also used to let anyone add any gmail address to a Google Groups group, and send out unfilterable spam as a message from that group.
https://lapcatsoftware.com/articles/2025/8/7.html
Edit: accidentally called sysdiagnose a spindump.
Support asked me to let them know when a contact vanishing did so they could gather logs from me phone.
Once I was finally able to see it happen, I reached out. Reported that it had just happened overnight. The customer support said it was too long of a time frame for engineers to investigate because "it generates a lot of logs and that's too much to go through". I could not believe their answer.
I just moved my contacts to Gmail and that was the end of it.
Hm. That is more than I ever got, but I also never bothered to report anything to any company after being ignored the first tries.
I also want to point out that I've seen similar corruption in the past, only in Lightroom. The culprit ended up being hardware, not software. Specifically, the card reader's USB cable. I've actually had two of these cables fail on different readers. On the most recent one, I replaced it with a nicer Micro B to USB C cable, and haven't had an issue.
Generally I'm frustrated with the state of USB. Bad cables are all over the place and I'm inclined to throw cables out if I have the slightest problem with them. My take is that the import process with Lightroom is fast and reliable if I am using good readers and good cables; it is fine importing photos from my Sony a7iv off a CFExpress card but my Sony a7ii has always been problematic and benefits greatly from taking the memory card out and putting it in a dedicated reader, sometimes I use the second slot in the a7iv.
If nothing else, it lets you get your card back much more quickly, as a file-system copy runs at ~1500MBps, which makes a difference when importing 50-100GB of photos.
I also don't delete the images off the memory card until they've been backed up from the disk to some additional medium.
Which means that if that bug has been present since the (now unsupported) Mavericks, tough luck!
For example, I'm probably not going to be upgrading to Tahoe until Sequoia's close to end of support life. I just upgraded to Sequoia last month from Ventura (decided to skip Sonoma since the various anecdotes of Sequoia made it sound like Sonoma-with-AI, with few apps breaking because of some new API change).
They could really benefit from how Google does it on Android and decouple it. Push updates to their first party apps via the app store like everyone else, and let the OS update on its own separate schedule.
In Sonoma or Sequoia they started bundling all Safari updates with macOS, but right now Safari 26 appeared as a separate update in Sonoma/Sequoia—-and it will likely stay that way.
Each thing separately can be explained, but when put together it’s somewhat messy..
What's the point of it? It is well known in the industry they ignore bugreports.
Also, this bug doesn't affect the majority of users, so it won't ever be fixed.
I'll tell you a secret though that kind of pisses me off. If you have shipped with a bug, that automatically lowers the perceived priority as well. You know, as opposed to introducing a new bug in a new release. "We've already lived with that old bug…" seems to be the mind set. Oh well.
To be sure though, if you saw the number of bugs that queue up for a popular app like Photos, you'd know that fixing all of them is not going to be possible — some kind of system of prioritization is required.
This mentality is all over BigTech: This bug didn't block release X-1, why should it block release X? So, it inevitably just sits in the backlog forever. If your releases are 90 days apart, any bug found has an average of 45 days to be fixed, or it ends up on the "we lived with it last time" list.
“This bug didn't block release X-1, why should it block release X?” Is actually a pretty strong argument and tough, but not impossible, to counter.
And the bug backlog only gets longer with time. It’s the price of greatly increased software complexity.
Why? If your app is used by billions of people, surely you can afford a few additional testers and engineers? Your app doesn't have an unlimited number of bugs: if you are solving them faster than you are introducing them, the number of bugs will eventually approach zero.
Sure, you'll always have newly-introduced bugs which are still waiting to get fixed, but if you've got an ever-increasing pile of bugs which have been around for years - even when they have been reported with easy-to-reproduce steps - then something has gone horribly wrong with your development process. At a certain point you have to stop shoveling new crap, rethink the workflow which is introducing so many new bugs, and slowly start fixing old bugs. The alternative is that your code will inevitably degrade into 100% bugs and become completely unusable and unmaintainable.
Unfortunately, in the real world, # of bugs solved per unit time does not scale linearly with # of developers - and, you eventually reach enough people that you can't effectively coordinate changes without wasting more time on processes than you're gaining by adding another person.
I've never worked at Apple and I don't know anyone on the Photos team, but I imagine a company at that scale probably has a good idea as to the optimal number of developers working on one application. Optimal to Apple probably involves optimal money spent:money earned ratio, not most bugs fixed per unit time, but I would wager those numbers are pretty similar anyways.
The most viable free options on windows seem to be sketchy cloud stuff designed to be inconvenient enough to upsell you. On Linux it's either built in already or trivial to install something that records locally and doesn't rug pull the user demanding money.
There is one more thing that gets factored into the bug triage. If the bug affects professional users (as in, data corruption from external media) - fuck them. Apple couldn't care less about professional users. The priority is to fix Photos.app for utility gauge pics and preferably in HEIC and other default settings.
This is unfortunately still true. I've had some radars de-prioritized with this exact reason and there are few things more infuriating.
It's really a sign of an overwhelmed, dysfunctional organization, but I heard from an ex-CoreOS guy that that's an intentional management choice, "people perform better under pressure"... (although I'm guessing Photos is not in the CoreOS org)
I would think the diffs would be telling to the right people.
It's on the front page of HN, so that's a good start!
As an engineer on a framework, I take pride in the code and want those trickier-to-repro bugs. And to your point, yeah, I can probably reconstruct in my mind a scenario, knowing my code, where it may be vulnerable.
Whoever screens bugs though is likely trying to 1) handle the huge backlog and 2) trying to spare the engineers bugs delivered with a shrug.
(I had my ass kicked by one bug in particular where I created a FileDescriptor on the main thread, did some things and then released the FileDescriptor on a background thread. Who knew the FileDescriptor code hung some important data it needed on some kind of thread-based storage that essentially required the caller to destroy the FileDescriptor on the same thread it was created on. Fix was to dispatch back to main when ready to release the FileDescriptor.)
Random is random, and random is clumpy, so maybe swapping parts is irrelevant, but... I wanted more detail how often the corruption happened throughout his replacement journey.
edit: also wth i just realized I went to "tenderlovemaking.com" at work. gross. lol.
maybe the randomness is based on the other apps he's using at the same time.
> I stopped checking the “delete after import” button
It’s more likely that things will be reversed: the old, battle-tested framework may have bugs, but it’s is less likely to have serious ones.
They should try to hunt down bugs in the existing code. A partial rewrite of parts that historically have many bugs may be in order, but a complete replacement? Unlikely to be an improvement.
Edit: Nevermind, the contents are vastly changed. This is like a different stream of input got used, or a buffer was written over with contents from another image.
”Glad” to see it was an actual bug.
I don’t even want to know what ZScaler thinks of “tender love making”.
C++ reference is one of these.
https://gearspace.com/
https://www.reddit.com/r/audioengineering/comments/mftc0g/ge...
It's like, we collectively prioritize efficiency over fun and then we wonder why life is not fun even though it is efficient.
Let's just leave aside the fact that the name genuinely made many people uncomfortable and unwelcome there (it did), it was also just teenage and immature. There's ways to inject personality and fun into a social experience without giggling about sex. Talk about lowest common denominator...
There are many personalities. Not everything has to be mature
Is a "mature personality" mature ? How do you test for it ? /s
The problem is that societal consesus is often wrong, and that image of a perfectly mature person actually does have a lot of problems with it. Every generation discovers this, and redefines that ideal.
40 years ago in my country a "mature man" was expected to take part in alcohol drinking contests until blackout. Nowadays a "mature man" is expected to drink as little alcohol as possible.
Neither attitude is actually about learning and forming a personal, informed opinion, both of them are about following whatever is currently in fashion.
Yes, they do.
It doesn't strike me as different from "porn" i.e. "unix porn" "food porn" etc, which are at least somewhat widely accepted. I assumed it was self-aware/deprecating humor, as in the people there recognized they were frequently replacing which gear they used beyond what might be strictly necessary.
It was colorful, in the way a lot of music and art is colorful. It's not like it's a sysadmin forum...
Ruby's community has been all sorts of whimsy and quirky over the years.
I very much enjoy Tenderlove being the community figurehead he is as is: kind, empathetic, genuine, open-minded, and generally wholesome.
> it's just awkward with interns to explain.
I've never had any trouble talking about Aaron Patterson a.k.a Tenderlove to coworkers, interns or otherwise.
It’s understandable why they changed their name.
279 more comments available on Hacker News