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.
That’s not how lossless compression works. No data is lost.
For example, if you zip a folder of images, then unzip them, the pictures come out with their original sizes and structure. Zip is lossless.
Let’s use the analogy of a dish sponge.
Let’s pretend you wanted to make a dish sponge smaller. Lossy compression would make the sponge smaller by cutting off parts and throwing them away. Lossless would make it smaller by squish the sponge, and it would return to its normal shape once you stopped squishing it.
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
That’s not how lossless compression works. No data is lost.
For example, if you zip a folder of images, then unzip them, the pictures come out with their original sizes and structure. Zip is lossless.
Let’s use the analogy of a dish sponge.
Let’s pretend you wanted to make a dish sponge smaller. Lossy compression would make the sponge smaller by cutting off parts and throwing them away. Lossless would make it smaller by squish the sponge, and it would return to its normal shape once you stopped squishing it.
For your analogy, you can’t put more water in a sponge that is completely saturated
Trying to compress a compressed file doesn’t really work - at least not for a meaningful gain in storage size with zip, bzip, 7zip, gzip, xz, lzma…