There’s not much to tell to the average user beyond “database did an oopsie”.
A post mortem would be fun for me as software developer, but is ultimately of limited value to me or lay people because the cause is already communicated.
I understand that the subject of the issue, it being photos, might be a bit touchy, but the mechanics and the nature of the bug is nothing special and anyone who moved past their “Hello, world” phase will immediately understand the kind of bug that was in play here.
Photos are stored “in” a photo library.
On Apple systems the photo library is just a package (i.e., essentially a folder) and in it is an SQL database that keeps track of photos and their attributes based on a GUID in some 70 odd tables.
The photos and videos themselves are stored in folders within that package (i.e., the file system). But it is ultimately the SQL database that is deemed authoritative and that decides what you see in the Photos app.
Different daemons and chron jobs use the database to sync photos to and from the cloud and to clean up photos when marked for deletion.
All it takes for this to occur is for a photo to be marked as deleted, without it actually being deleted in the underlying folder, for it to seem deleted.
And all it takes for it to show back up is for 17.5 to index through the folders and based on what found “repair” the database.
The database also gets changed from time to time, so it could also simply be a new way of keeping track of deleted photos and in the process of migrating to the new database version taking a conservative approach and assuming that photos that are still present to be wrongly marked as deleted.
It’s always better to restore and let the user decide than to make destructive assumptions.
After this process resurfaces photos then they get synced with iCloud, just like any other photo.
The implication that this doesn’t explain the resurfacing of old photos from years ago and many devices ago is rather weird.
Most people don’t start fresh when they get a new Apple device and instead transfer data over or restore form a backup, putting in place the corrupted database. To say nothing of the database file being synchronized across devices via iCloud.
In fact, that only makes the corrupted database explanation more likely.
In the earlier days of iOS, Apple was still finding its way on how to effectively manage the library, making some significant overhauls in addition to overhauls to switch from Photo Stream to iCloud Photo Library.
So it’s not unlikely it was during that period this issue snuck into the database.
Like I said, it’s unfortunate that it affects photos, but otherwise not a shocking bug by any means and the solution to include orphaned photos back into the library as opposed to destructively deleting them is good practice.
The only thing that might’ve been better is if the user was provided with a prompt informing them of the find and perhaps asking them to make a choice.
It’s clear however that they didn’t think it would be an issue that would affect many users and using scary technical words like “corrupted” go against the kind of language and UX Apple tries to stick to.
A miscalculation perhaps, but hardly worthy of the drama that it’s being milked for.
Our friend above is likely under NDA, so they won’t be able to comment on intricacies.
Luckily, I am not under an NDA, and I can tell you that the Reddit post is nonsense. A straight-up lie when you assume bad faith or poor recollection if you assume good faith.
The scenario described there, and further expanded upon by OP in comments is pretty much impossible. I hedge only because of an astronomical unlikely probability that everything in the universe aligned perfectly.
As you seem to be aware, encryption keys are involved, and that involvement lies at the root of the impossibility.
Say you’re inclined to believe that the Secure Enclave that stores this key has a massive bug that doesn’t delete the key upon wiping. That alone wouldn’t explain a scenario like that.
In addition to not deleting that key, the OS must’ve been unable to detect and try to use that key until some serious potent code was introduced in 17.5.
Also, during the wipe, the encrypted data partition that goes with the key must’ve not been deleted and gone unnoticed by the OS up until 17.5.
In addition, the OS must’ve kept the key intact, and ignored the existence of the encrypted data partition. Creating a new encrypted data partition with an accompanying key and acting as if it was all business as usual.
Then, suddenly, 17.5 comes around. It would have to have seen two encrypted data partitions with two encryption keys, mounted the most recent encrypted data partition, and decrypted it with the most recent encryption key without any issues and hiccups, only to then do something quite miraculous.
It would, at that point, do something that it was never designed to do, namely decrypt and mount the old data partition, all while the most recent one is already mounted, grab only a bunch of old photos from a corrupted database, nothing to else, and merge it into the database located on the most recent data partition.
All this while ignoring many complexities related to key pairs tied to iCloud accounts that I’ve omitted for simplicity’s sake and without throwing up a single error, much less a respring or, more likely, a kernel panic.
Just the part about mounting two partitions alone would cause huge issues.
It’s nearly impossible to do this on purpose due to hardware limitations on storage and the way the Secure Enclave works. To entertain a string of bugs that would execute this perfectly is just silly.
Who needs jailbreakers and the likes of Pegasus spending hours designing chain exploits when the OS stumbles into perfectly executed bugs that defy the law of physics?
Just seems odd to me that he would make that whole story up.
I know it's the internet but there doesn't seem to be a compelling motivation for someone to do that.
I think it's reasonable to expect a more detailed explanation from Apple, when it's closed source software from a company that claims to value privacy, yet exhibiting a confidence-eroding problem like this.
Haha this had me chuckle as a native Dutch speaker.
I will admit that they nailed the German-Dutch accent.
However, the weird choice to use “translatie” which, while technically is a Dutch word, wasn’t common even back in the period this is supposed to take place and feels more like a lazy translation of… well the English word “translation”, combined with, what I can only describe as “just blurt it out as fast as you can” direction, makes this very comical.
To say nothing of the fact that embossing a document in Germany, and Europe in general, is extremely rare and certainly not common on your garden variety receipt or invoice (basically never). They were a bit more common pre-90’s though.
Without the aim of trying to insult anyone, frills like that are more common in the US when trying to emphasize the official nature of documents (e.g., notary public embossing).
Even so, on top of all that, it would make exactly zero sense for the embossing to be the EU stars.
It isn’t even the European stars – the Flag of Europe always had 12 stars, whereas the embossing has 16 stars.
“Ah, 16 stars, because Germany has 16 federal states”, you'd say at first thought. But while the German Red Cross organization has sub-organizations, the Landesverbände, those only partially mirror the modern 16 federal states. Some Landesverbände predate the modern federal states and are instead for more traditional German regions. Instead of a single Landesverband for the state of Nordrhein-Westfalen [1] there are two Landesverbände, one for Nordrhein, one for Westfalia-Lippe. In Lower Saxony there is an extra Landesverband for Oldenburg, in Baden-Württemberg there is an extra Badischer Landesverband. That makes 19 regional sub-organizations, but there aren’t 19 stars.
And all of these 19 regional subs predate 2001. I can’t really see a reason for the DRK in 2001 to use 16 stars.
[1] Nordrhein-Westfalen (North Rhine Westfalia) was created forcefully by the British Military Administration in 1946 out of the former prussian provinces of the Rhine and parts of Westfalia (and small Lippe!) in the creatively named "Operation Marriage". Nobody thought a union between the lively Rhinelanders and the laconic Westfalians (and the Lippians!) could work given the differences – but it seems to work mostly great. Nobody thinks of seceding. Must be the first time in history.
The EC is not the final arbiter in this. It’s just an executive body.
Apple complied with what they think will withstand adjudication by the CJEU and leaves the rest for the EC to act on so they can appeal it with the CJEU.
Given the EC’s poor track record in terms of getting their fines and decisions overturned by the CJEU, I too would do it this way, no matter how loud the EC likes to bark and show their teeth.
Especially considering the DMA is poorly drafted and in Europe, unlike in the US, the courts aren’t ghostbusters that go seeking for “spirits” of the law.
Whether the EC thinks so or not, Apple is in compliance with the straightforward parts of the DMA as well as with the more vague parts on the basis of reasonable interpretation, to be adjudicated by the CJEU.
In law there’s very little that’s certain, as such it’s bad form to make predictions, but I’m pretty confident in saying that the CJEU isn’t going to open Pandora’s box by prohibiting Apple from charging a reasonable fee for their IP.
Is there a particular reason you’re not putting .zshrc in the user’s home folder ~/.zshrc?
In any case, / root and /etc (to an extend) are part of the system volume (or rather the system volume snapshot if we want to be pedantic). With some exceptions Apple considers that fair game.
There’s a bunch of symlinking and firmlinking done to make it look like one coherent whole but only the stuff on the data volume is safe.
That said, if for whatever reason you need to put something in root you can create your own synthetic firmlink[0] with /etc/synthetic.conf.
I believe some also reported success by simply making a subdirectory under /etc and use that instead but YMMV.
In fact, I used to get kernel panics from time to time with USB hubs until a couple of major revisions ago.
What I’m running now, in part via monitor USB hub, is so far beyond the scope of what I expect to be part of QA and intended support that I’m surprised it’s not giving me any issues.
Windows has become a hodgepodge of code bases from a variety of time periods and philosophies, some of which leans on some ancient stuff that can’t be touched.
Hell, they had to skip Windows 9, just to prevent breaking 95/98 software from braking.
The average SW engineer here in HN wouldn’t know how fast they’d get to a keyboard to complain if they were to find a codebase like that at their job.
That’s not to say it’s necessarily bad, even if it can be cumbersome, it’s just to highlight the cost of maintaining that compatibility and a difference in philosophy.
A post mortem would be fun for me as software developer, but is ultimately of limited value to me or lay people because the cause is already communicated.
I understand that the subject of the issue, it being photos, might be a bit touchy, but the mechanics and the nature of the bug is nothing special and anyone who moved past their “Hello, world” phase will immediately understand the kind of bug that was in play here.
Photos are stored “in” a photo library.
On Apple systems the photo library is just a package (i.e., essentially a folder) and in it is an SQL database that keeps track of photos and their attributes based on a GUID in some 70 odd tables.
The photos and videos themselves are stored in folders within that package (i.e., the file system). But it is ultimately the SQL database that is deemed authoritative and that decides what you see in the Photos app.
Different daemons and chron jobs use the database to sync photos to and from the cloud and to clean up photos when marked for deletion.
All it takes for this to occur is for a photo to be marked as deleted, without it actually being deleted in the underlying folder, for it to seem deleted.
And all it takes for it to show back up is for 17.5 to index through the folders and based on what found “repair” the database.
The database also gets changed from time to time, so it could also simply be a new way of keeping track of deleted photos and in the process of migrating to the new database version taking a conservative approach and assuming that photos that are still present to be wrongly marked as deleted.
It’s always better to restore and let the user decide than to make destructive assumptions.
After this process resurfaces photos then they get synced with iCloud, just like any other photo.
The implication that this doesn’t explain the resurfacing of old photos from years ago and many devices ago is rather weird.
Most people don’t start fresh when they get a new Apple device and instead transfer data over or restore form a backup, putting in place the corrupted database. To say nothing of the database file being synchronized across devices via iCloud.
In fact, that only makes the corrupted database explanation more likely.
In the earlier days of iOS, Apple was still finding its way on how to effectively manage the library, making some significant overhauls in addition to overhauls to switch from Photo Stream to iCloud Photo Library.
So it’s not unlikely it was during that period this issue snuck into the database.
Like I said, it’s unfortunate that it affects photos, but otherwise not a shocking bug by any means and the solution to include orphaned photos back into the library as opposed to destructively deleting them is good practice.
The only thing that might’ve been better is if the user was provided with a prompt informing them of the find and perhaps asking them to make a choice.
It’s clear however that they didn’t think it would be an issue that would affect many users and using scary technical words like “corrupted” go against the kind of language and UX Apple tries to stick to.
A miscalculation perhaps, but hardly worthy of the drama that it’s being milked for.