iOS resurrected photo bug fixed with iOS 17.5.1 detailed by Apple

AppleInsider

Deleted photos reappeared on some iPhones running iOS 17.5, and Apple has finally clarified how that might occur -- it isn't iCloud.

Deleted photos were reappearing in people's Photos app

The iOS 17.5.1 update that fixed the reappearing photos bug had a brief description involving a corrupted database. Apple has clarified what exactly that meant and explained how a photo might reappear even after deleting it years prior.

According to information Apple shared with 9to5Mac, photos reappeared due to local corrupted files surviving between device upgrades thanks to backups and transfers. Apple never had access to deleted photos, nor was the corrupted data maintained as part of iCloud Photos sync.

In other words, when a photo is deleted in the library, it is truly deleted in the OS. However, because of how NAND storage works, the memory used to store the photo is marked as available rather than immediately deleted.

A bug caused some files to persist due to database corruption. Since the error occurred outside of the photos library, the deleted files never left the device unless a device transfer or backup occurred.

In iOS 17.5, these files were restored from the corrupted state and repopulated the Photos app. Apple called it a rare occurrence and didn't share how many users were affected otherwise.

If a device was wiped correctly using the "Erase All Content and Settings" function, the corrupted database would be erased, too. Apple confirmed that the single Reddit account of someone else's photos appearing in their library wasn't real.

If old photos did reappear, simply delete them again. The fix in iOS 17.5.1 fixed the problem that caused the corrupted database to persist and bring back old deleted photos, but it didn't re-delete the photos that had been restored.



Read on AppleInsider

maltz

In other words, when a photo is deleted in the library, it is truly deleted in the OS. However, because of how NAND storage works, the memory used to store the photo is marked as available rather than immediately deleted.

That has nothing to do with NAND - that's just how filesystems work.  But what *is* because of how NAND works, that space marked as unused should have been TRIMmed for performance and wear-leveling purposes.  I've never heard of an OS that doesn't do that - it's shocking to learn iOS apparently doesn't.

JustSomeGuy1

maltz said:

In other words, when a photo is deleted in the library, it is truly deleted in the OS. However, because of how NAND storage works, the memory used to store the photo is marked as available rather than immediately deleted.

That has nothing to do with NAND - that's just how filesystems work.  But what *is* because of how NAND works, that space marked as unused should have been TRIMmed for performance and wear-leveling purposes.  I've never heard of an OS that doesn't do that - it's shocking to learn iOS apparently doesn't.

Correct about NAND and filesystems. But there's still a giant steaming pile of bullsh!t here, and it has nothing to do with whether or not TRIM is implemented. (And BTW it would be a mistake to infer from this nonsense that TRIM isn't implemented.)

Filesystems are a series of blocks. When blocks are released back to the filesystem, they no longer have any connection to each other. There is no realistic mechanism by which free filesystem space could magically reappear as the file it once was. You'd need purpose-built software to try to reconstruct a deleted file, and it may actually be impossible on a filesystem like APFS. (It was not on HFS; several companies sold such software.) And even if somehow that file got reconstituted, there's no mechanism by which it could suddenly reappear in the Photos app.

What Apple probably said, which got mangled by the reporter, is:

- the photo was marked for deletion in Photos. This does nothing to the file itself, it's just marked as due to be deleted in the Photos database.

- due to some corruption in the Photos database, the file wasn't deleted upon expiry, and some vestige of its metadata was left in the database.

- in 17.5, some new error detection and correction code was added to Photos. It detected those vestiges and fixed the database, returning the photo to its album.

In all this, nothing happened to the file itself.

Assuming Apple isn't lying about it all being on-device, this is probably the only possible scenario.

MacPro

A few of us suggested it was likely a local device glitch when this broke, but certain folk pointed fingers at Apple's iCloud security.  Hopefully they will fall on their knees and apologise

sunman42

maltz said:

That has nothing to do with NAND - that's just how filesystems work.  But what *is* because of how NAND works, that space marked as unused should have been TRIMmed for performance and wear-leveling purposes.  I've never heard of an OS that doesn't do that - it's shocking to learn iOS apparently doesn't.

I've never heard of a filesystem on any OS that invokes TRIM on every file delete — that would be wildly inefficient. TRIM was designed for regular, custodial duties, run daily or hourly, wasn't it? A lot can happen to a file system in that kind of time.

macxpress

I think it was important that Apple explained why this happened to certain users. I know people will blow this off as a PR stunt and think it's just Apple covering its ass but to me it's a very logical explanation that most users won't comprehend because they're most likely not tech savvy. They just see news headlines and run with it not knowing or understanding why something like this actually happened. But it's great for the Apple haters out there who will just stupidly take these headlines and run with them thinking they're cool and funny. 

gatorguy

MacPro said:

A few of us suggested it was likely a local device glitch when this broke, but certain folk pointed fingers at Apple's iCloud security.  Hopefully they will fall on their knees and apologise

I'm glad to see Apple properly explain what "database corruption" meant. Had they done this in the first place, adding a single word, "local," then multiple tech articles wouldn't have posted suspicions, and thousands of previously concerned readers of those articles wouldn't now be missing Apple's explanation written on a traditionally no-one-reads-the-news Friday.  

appleinsideruser

gatorguy said:

MacPro said:

A few of us suggested it was likely a local device glitch when this broke, but certain folk pointed fingers at Apple's iCloud security.  Hopefully they will fall on their knees and apologise

I'm glad to see Apple properly explain what "database corruption" meant. Had they done this in the first place, adding a single word, "local," then multiple tech articles wouldn't have posted suspicions, and thousands of previously concerned readers of those articles wouldn't now be missing Apple's explanation written on a traditionally no-one-reads-the-news Friday.  

Feeling smug now, despite the attitude and votes in https://forums.appleinsider.com/discussion/236474/new-ios-ipados-update-fixes-reappearing-photos-bug

maltz

sunman42 said:

maltz said:

That has nothing to do with NAND - that's just how filesystems work.  But what *is* because of how NAND works, that space marked as unused should have been TRIMmed for performance and wear-leveling purposes.  I've never heard of an OS that doesn't do that - it's shocking to learn iOS apparently doesn't.

I've never heard of a filesystem on any OS that invokes TRIM on every file delete — that would be wildly inefficient. TRIM was designed for regular, custodial duties, run daily or hourly, wasn't it? A lot can happen to a file system in that kind of time.

You must have missed the part where some of these pictures were years old.  In any case, it sounds like the files probably weren't deleted at all, just hidden from view, due to the DB corruption.  So the TRIM issue is probably moot after all.

FYI - TRIM is run weekly by default in Windows and most Linuxes I'm aware of.  macOS, of course, doesn't talk about details like that, but it does claim to do it.  However, depending on how you mount the filesystem in Linux, it is possible to issue TRIM commands at the time of file deletion.  I have run systems that way, just to see what happens, and it's fine for general use, with the drives I was testing.  Ideally, the drive would cache the TRIMs until it wouldn't affect performance anyway, so that may have been what was going on in my case.

netrox

AppleIns 

In other words, when a photo is deleted in the library, it is truly deleted in the OS. However, because of how NAND storage works, the memory used to store the photo is marked as available rather than immediately deleted. 

That makes no sense at all. It has nothing to do with NAND. Once rm (which MacOS uses internally to remove files) removes its entries to files, they're gone, forever. You cannot re-reference to them again. NAND may not delete the actual data but it's permanently hidden and will never be accessed again. TRIM is used to rearrange blocks (all modern OS's do it automatically) and even with that, the OS never knows which block because it is done on SSD's side. The corrupted database however can have old files and may reference again. You can copy databases on any storage devices. If the DB is corrupted, it may reference to wrong files or destroy files. The exact mechanism on how a corrupted DB can cause old photos to show up is unclear. I would say it's likely a bug, not a corrupted DB that failed to completely remove data during optimization which happens from time to time.