4 ms·

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-

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

Grimeton 2y ago
Sorry, but this is nonsense. You don't unlink a file in a filesystem and it magically reappears. Everyone who's ever had an issue of recovering deleted data would be happy to have had that option. So that's clearly not something that has happened here. Also when I assume that's what's going on, then the phone would make a low level block by block backup of the raw storage device. You really trying to tell me that's what's going on here? And on top of that, that easy recovery of unlinked files, randomly scattered across hundreds or thousands of blocks in the filesystem can just easily be "relinked" and just reappear out of thin air? You got to have zero idea about how all of this works or are one of those corporate shills but this is just the biggest nonsense there is.
- tpmoney 2y ago
  Well that was an unnecessarily hostile response, especially since you appear to have misunderstood or misread what I wrote. I did not say that the files were unlinked at the filesystem level and somehow recovered as is. I said that they likely were doing a similar user space soft delete where the files themselves were note actually deleted. In fact, my second sentence is: > 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. I referenced both the unlinking that a program like `rm` would do, and the wear leveling tech in SSDs both as examples of how we already have similar concepts of soft deletes at other layers of the stack. My suggestion was that Apple has added an additional layer on top of this, which does soft deletes at the file presentation layer. That explains both how the files could move with backups (and without "block by block backup") and how they can just be "relinked and just appear out of thin air". I'm sorry if I wasn't clear enough in distinguishing what I was suggesting Apple was doing, and the analogies I was using as a comparison point. Perhaps in the future, you could assume good intent and ask for clarification if I haven't been clear enough for you, rather than accusing me of being stupid or a shill.
  - Grimeton 2y ago
    [dead]
- 2y ago

Grimeton 2y ago

Sorry, but this is nonsense. You don't unlink a file in a filesystem and it magically reappears. Everyone who's ever had an issue of recovering deleted data would be happy to have had that option. So that's clearly not something that has happened here. Also when I assume that's what's going on, then the phone would make a low level block by block backup of the raw storage device. You really trying to tell me that's what's going on here? And on top of that, that easy recovery of unlinked files, randomly scattered across hundreds or thousands of blocks in the filesystem can just easily be "relinked" and just reappear out of thin air? You got to have zero idea about how all of this works or are one of those corporate shills but this is just the biggest nonsense there is.

tpmoney 2y ago
Well that was an unnecessarily hostile response, especially since you appear to have misunderstood or misread what I wrote. I did not say that the files were unlinked at the filesystem level and somehow recovered as is. I said that they likely were doing a similar user space soft delete where the files themselves were note actually deleted. In fact, my second sentence is: > 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. I referenced both the unlinking that a program like `rm` would do, and the wear leveling tech in SSDs both as examples of how we already have similar concepts of soft deletes at other layers of the stack. My suggestion was that Apple has added an additional layer on top of this, which does soft deletes at the file presentation layer. That explains both how the files could move with backups (and without "block by block backup") and how they can just be "relinked and just appear out of thin air". I'm sorry if I wasn't clear enough in distinguishing what I was suggesting Apple was doing, and the analogies I was using as a comparison point. Perhaps in the future, you could assume good intent and ask for clarification if I haven't been clear enough for you, rather than accusing me of being stupid or a shill.
- Grimeton 2y ago
  [dead]
2y ago