4 ms·

There are far too many things that don't add up: - According to reports we have photos resurfacing that are 10 years old [1] - The oldest phone supported by i

• tpmoney 2y ago
  The most obvious answer is that files aren’t deleted from the filesystem until they need to be overwritten. Instead they are marked as deleted and just left un-displayed / un-indexed until they’re finally overwritten by some need to use that space. Imagine it like a delete just always moves your files to the trash/recycle bin, but instead of the user having to manually empty the trash, it just gets reclaimed when necessary. That’s how you can do “shake to undo” that will undo deleting a file. Eventually your undo history/the “recently deleted” timer expires and for all practical intents the files are “deleted”, but they’re still there just like in most modern file systems they’re also still there (just unlinked) unless you explicitly overwrite them. Even then with modern tech like wear leveled SSDs they might still be around at some lower level. So if the whole user space is copied in backups, that would include these deleted files. The growing backup size wouldn’t be a concern because the growth is in “reclaimable” space and it also allows having multiple backups going back in time while being able to de-dupe / hardlink common files between backups (a la Time Machine). Additionally if you’ve upgraded phones via the migration assistant, not only would the files have come with if the whole user space is copied (again so that backup / undelete history could be preserved) but unless you start filling up the new phone with even more data than you had before your now larger phone has more capacity to be written to before the deleted files need to be reclaimed. So a file you deleted 10 years ago might still be there because going from 4GB disk space to 128GB means you’ve never needed to overwrite that original 4GB disk space. Now you introduce a bug that either scans the trash or doesn’t check that deleted flag properly and suddenly all these old files are re-appearing, photos are just the most visible ones but voice mails (which are just audio files on your phone) and notes would be affected just as much depending on what the scanner was scanning for. If this article is one the right trail, it looks like scanning photos/media for subject tagging/recognition. Not sure why that would also resurface voicemails, but maybe a different similar change was made in that code path too. Unfortunately even with it being all benign this is the sort of user facing bug that shatters confidence. Maybe only the system processes can scan the deleted / trash area of the disk, but the fact that it can as part of routine behavior as opposed to an explicit action (like a “Recover data” button/request) means users will question whether other apps can trigger a similar bug. If the sandboxing model holds, even if they could trigger such a bug it would only resurface their own data, but even that’s going to reasonably make people uncomfortable. We’ve largely come to terms with “data recovery is possible because your filesystem doesn’t delete things just unlink them”, but likewise your file system doesn’t try to relink/ scan for unlinked files as part of any regular interaction. Having a user space version of the same behavior isn’t inherently bad, but having those soft deletes resurface-able as part of routine OS behavior is not great to say the least