Media library apps have been doing this kind of stuff forever. An index of the files + metadata allows for a better and more performant experience. But, if an entry in the DB gets pooched, file remains on the drive and is hidden from the user.
Many media library apps actually have a way to repair and or rebuild the library DB if it gets out of sync or corrupted. iTunes straight up put that feature in the menu bar. The Photos app will do it if you launch the app while holding command-option.
Back when iPods were king, how many of us had old music come back to life after a fucked up iTunes library was rebuilt? It’s kind of a similar issue.
Given the rarity of this, it could’ve just been the normal random stuff that happens in computer land. Requests that don’t complete because they were interrupted by a crash, the rare bad block, etc. Or maybe it was just a bug that occasionally reared its head under certain circumstances.
Whatever it was, it wasn’t the first time a piece of software had an index that was messed up and out of sync with the stored files.
As for the iPhone storage thing you mentioned, I don’t know what you’re talking about. There was a IOS 17 bug early on where people mentioned that the OS needed a restart to claw back space from temporary install files and caches.
That said, the corrupted DB we’re talking about appears specific to the photos app. It’s not the file system index. It’s basically a glorified preference file.
E.g. iCloud says it’s using 13.4 GiB to store photos, Settings -> General -> iPhone Storage says I can save 15.5 GiB because they’re backed up on iCloud, and if I use idevicebackup2 to pull everything off the phone, there are 21.7 gigs of photos
I’m wondering if these discrepancies are related to the photo app not actually deleting pictures from the filesystem
Weird. I’d bet money on syncing issues, compression, etc. But who knows, if you have a Mac you can rebuild the library, let that sync, and see what happens.
Then how would they be training AI on it? If they don’t have it? If it’s on device what’s the problem? Deleting a photo doesn’t wipe the bits to 0, it never has
I’d still like a deeper dive into how database corruption led to data restoration
It seems like deleting a photo must just be removing the entry from the SQLite database, and not actually deleting the photo?
Media library apps have been doing this kind of stuff forever. An index of the files + metadata allows for a better and more performant experience. But, if an entry in the DB gets pooched, file remains on the drive and is hidden from the user.
Many media library apps actually have a way to repair and or rebuild the library DB if it gets out of sync or corrupted. iTunes straight up put that feature in the menu bar. The Photos app will do it if you launch the app while holding command-option.
Back when iPods were king, how many of us had old music come back to life after a fucked up iTunes library was rebuilt? It’s kind of a similar issue.
Sure, an index makes sense for quick search, but I’m confused why deleting it wouldn’t remove it from the filesystem too
Is that why iPhones seem to have no idea how much disk space they’re using?
Given the rarity of this, it could’ve just been the normal random stuff that happens in computer land. Requests that don’t complete because they were interrupted by a crash, the rare bad block, etc. Or maybe it was just a bug that occasionally reared its head under certain circumstances.
Whatever it was, it wasn’t the first time a piece of software had an index that was messed up and out of sync with the stored files.
As for the iPhone storage thing you mentioned, I don’t know what you’re talking about. There was a IOS 17 bug early on where people mentioned that the OS needed a restart to claw back space from temporary install files and caches.
That said, the corrupted DB we’re talking about appears specific to the photos app. It’s not the file system index. It’s basically a glorified preference file.
E.g. iCloud says it’s using 13.4 GiB to store photos, Settings -> General -> iPhone Storage says I can save 15.5 GiB because they’re backed up on iCloud, and if I use idevicebackup2 to pull everything off the phone, there are 21.7 gigs of photos
I’m wondering if these discrepancies are related to the photo app not actually deleting pictures from the filesystem
Weird. I’d bet money on syncing issues, compression, etc. But who knows, if you have a Mac you can rebuild the library, let that sync, and see what happens.
https://support.apple.com/guide/photos/repair-the-library-pht6be18f93/mac
I’d disregarded compression as a possibility because the wording is “full resolution photos and videos are safely stored in iCloud”
There is lossless compression. Not saying that’s the cause of the varied number, but it is a common thing.
They’re already using HEIC/HEIF
I would be disappointed if they’re compressing it even more on iCloud. You can’t generally meaningfully compress a compressed file
Yeah they keep it for AI training.
Such bs.
@Valmond @ozymandias117 oh so we’re still doing the baseless-accusation-without-knowing-how-it-works thing?
They keep deleted photos for a time in iCloud in case someone comes looking for them
Every cloud storage provider does it, every mail server does it, it’s incredibly commonplace
The article specifically states that iCloud wasn’t related to the bug
@ozymandias117 I see now
Then how would they be training AI on it? If they don’t have it? If it’s on device what’s the problem? Deleting a photo doesn’t wipe the bits to 0, it never has
I never made that claim, my man
I just wanted some more information about how the on-device database corruption led to restoring pictures
Those are generally opposites
On spinning disks, it’s significantly easier to restore data after a delete, but it’s not normally as easy on flash storage like they’re using