Aghast iOS users report long-deleted photos back from the dead after update Some iPhone users are reportedly seeing photos they had previously deleted resurface on their devices ever since updating to the latest version of iOS. The user reports originate from Reddit, and it's not just a couple of Apple users experiencing issues. By our count, 16 people who deleted their photos say they've come back. …
" Instead of doing the intensive process of overwriting files with zeroes every time someone wants to delete something, most of the time the area where such code is stored is marked as free to use, and the data will be overwritten over time by newly made files."
As does Windoze. The oddity is the re-emergence of photos deleted 14 years ago, which is much less likely to be explained by this. Sounds more like unannounced archiving by apple.
Photos that old don't have anything to with local filesystem corruption, so it isn't an issue with the device itself. Must be type of database corruption on iCloud that don't allow those photos to be properly "deleted" - that would explain the reports that the same few keep coming back despite repeated deletion.
These photos may be incorrectly recognised as potentially criminal and so held pending possible FBI investigation. I vaguely recall something to the effect that the FBI database checks illicit porn by comparing against ID strings culled from known images. Sometimes a perfectly normal photo will produce the same ID string as a known verboten one. The false positives are weeded out by humans rather than software. They may not bother checking small numbers of images until a specific total is reached, but may retain all of them, even if they are deleted. A bug may have 'restored' them to a user. Just a possible scenario.
That’s against a US company with foreign subsidiaries. They still need to obey local laws.
EU GDPR is similar against global companies with EU data or EU companies with overseas subsidiaries.
I could not however be prosecuted by the Fed’s in London though for a Cloud Act breach. That’s owned by my US HQ.
Photos
Whether an item has been marked as a favorite, hidden, or marked as deleted.
What Tim Apple wants to with a hoard of photos is anyone's guess.
Shocked to the extreme! I know for sure there are photos that have gone missing from iPhoto\Photos\iClumsy'scloud. A good portion of the photos of my son's first year, from 2010!! Poof...
I also read on another site(I know!) that these were NSFW photos coming back?? Algorithm gone awry?
FYI: Because people make mistakes, the “photos” app marks photos as deleted for 30 days. There is a “deleted photos” folder where you can get them back for 30 days. To permanently delete a photo _now_, find it in “deleted photos” and delete it there. FaceID is needed to show “deleted” photos.
“Not overwriting with zeroes” is a red herring. There is no api in iOS that lets you undelete deleted files. These pictures are _not_ deleted and then undeleted. What is possible that photos that should have been deleted after 30 days somehow were removed from the iPhoto app without actually being deleted. In that case they wouldn’t have been overwritten with zeroes anyway.
Most likely these photos were in iCloud and never deleted because of some bug, but never shown because iPhoto believed they didnt exist anymore. Now for some reasons after an iOS update iPhoto thinks “maybe I lost some photos, let’s see what’s _really_ in iCloud” and finds these photos.
As the photos are in iCloud and pushed to/pulled by the phone the only paragraph that matters is the third one, but then the question is why were they never deleted in the first place?
There are two possibilities - they are supposed to be in iCloud but some bug in all Apple devices meant they were not shown, or they are not supposed to be in iCloud but some bug in all Apple devices meant they are shown.
The second possibility is something very serious indeed for a company that has spent years saying they look after your privacy. Now, the questions raised are what are they doing with your photos, can you trust them to really delete your data, and have they spent years breaching GDPR?
File systems no longer decide where data is stored on a disk-drive [0].
Gone are the days of data being stored in a known physical location on a disk (cylinder, head, sector). CHS has long since been replaced by Logical Block Address - LBA. Here a separate computer, embedded in the disk-drive[1] is now responsible for deciding where on the disk-drive[2] the data should actually reside.
By allowing the disk-drive[3] controller to map logical blocks to physical storage various magics can be achieved, namely:
o Faster performance - data blocks may span multiple physical entities (i.e. multiple heads of a spinning disk or several FLASH devices)
o Even Faster performance in Solid State Disks - Blocks of FLASH need to be erased before they can be re-written, by dynamically mapping Logical blocks to the next 'empty' physical block there is no need to wait for the physical block to be erased before it can be re-used. Old physical blocks can then be erased by the controller when host has finished accessing the device. this feature is also known as dynamic wear levelling, because it has the affect of moving the physical storage around all available blocks, and therefore increasing the service life of the device when the same Logical Block address is repeatedly written.
o Improved production yield - Production of storage is not perfect, sometimes not every physical block works reliably when manufactured. By over-provisioning physical blocks bad blocks may be mapped out whilst still maintaining the advertised capacity of the disk-drive[4].
o Improved longevity - Over provisioning capacity by more than statistically necessary to ensure a satisfactory yield means spare blocks are now available when a physical block fails [6]
o Increased longevity - Mostly pertaining to solid state devices, but applies to a lesser extent to spinning disks, each block only has a finite life expectancy (SLC FLASH lasts longer than TLC which lasts longer than MLC), so wear static levelling is applied. Unlike dynamic wear levelling described above (as a performance enhancement feature), here the controller copies blocks of data that have low erase counts into blocks that have higher counts in an attempt to even out the service life of the drive so that all blocks age at a similar rate.
Of cause if your disk-drive AND file system support the TRIM command then deleted files can be simply put back into the pool of free physical blocks and the disk-drive's controller will erase the physical data when it has some spare time... However this will not erase old fragments of a file that has been updated but there are un-errased physical blocks waiting in the dirty queue.
I believe there are commands now available to force erasure of the dirty queue as well as a secure erase of the entire drive, but these enhancements came about after I stopped developing SSDs
/Rattus
[0] Disk-drive - Generic term for any Non-Volatile / persistent storage device
[1] Disk-drive - In days of old 1's and 0's were stored on spinning platters of rust called disks, consisting (in some part) of ferrous metal, information could be written or read to these disks by use of electro magnets. Whilst little of this steam driven technology remains today, the naming convention, and underlying protocols still persist.
[2] Disk-drive - Device for storing and retrieving patterns of 1's and 0's curated by a controller that is responsible for the actual storage. Storage is presented to the host system as a contiguous series of blocks starting at block address 0 and working upwards, however the controller is responsible for mapping Logical Blocks to Physical storage anywhere it likes.
[3] Disk-drive - this sub-definition exists only to continue the series of sub-definitions whenever disk-drive[4] is mentioned
[4] Disk-Drive - It may come as a surprise but bad block management is not something unique to FLASH based disks, this applies to spinning disks as well. Yields of multi-layer FLASH (MLC) are worse than that of Two Layer FLASH (TLC) which in turn is worse than that of single Layer FLASH (SLC), however density (and hence cost) of MLC is > TLC > SLC by large margins, thus making MLC financially most attractive even if a relatively greater amount of over provisioning is required.
[5] Disk-drive - recursion of disk-drive[5] achieved
[6] see SMART - this reports statistics on the available unallocated physical blocks available, as well as tracking the number of erase cycles blocks have been put through and therefore projected remaining life expectancy of the disk-drive[5]
Nevertheless the smart storage device should present a consistent view of the LBA to the host - what was in a given LBA address should still be in that LBS address until the host changes it. Likewise the host should maintain a consistent view of the file system - even if low-level access to LBA addresses might turn up data marked as deleted a file deleted at OS level should remain deleted.
"Nevertheless the smart storage device should present a consistent view of the LBA to the host - what was in a given LBA address should still be in that LBS address until the host changes it. Likewise the host should maintain a consistent view of the file system - even if low-level access to LBA addresses might turn up data marked as deleted a file deleted at OS level should remain deleted."
Exactly. I couldn't agree more.
Just because a file has been deleted as far as the file system is concerned does not mean that it has been deleted fully. If the File System doesn't explicitly tell the storage media that the Logical blocks are no longer wanted (i.e. trim) AND if those same logical blocks are not written to in the intervening time then the files will still be there.
Now it only takes some tinkering around the file system structure to get those blocks back - if the FS only removes that start index pointer to the file that could be as little as a single entry in a table...
Given the size of modern disks, it is easily conceivable that 'files' can be recovered after a few years of most people's use.
Rattus: Just because a file has been deleted as far as the file system is concerned does not mean that it has been deleted fully. If the File System doesn't explicitly tell the storage media that the Logical blocks are no longer wanted (i.e. trim) AND if those same logical blocks are not written to in the intervening time then the files will still be there.
cow: Deleting a file means its no longer avialable as a file. Deleting a file does not mean the previously occupied blocks on the device are zeroed or whatever.
If you have to read blocks directly from the device and somehow guess which make up a previous file, the data is no longer a file but blocks of stuff that may or may not be a file.
That is what the SSD “trim” command is there for. OS deletes say a 500 MB video. Removes it from its directory, and then issues a trim command saying “this data is not needed anymore, you can wipe it at any time”. Now the controller deletes the mapping from logical to physical block, and there is no API at the controller level to read the block.
Correction: MLC (Multi-Layer cells) is the name for dual layer, invented before anyone realised we could have three or four layers one day. TLC is triple layer cells, QLC is quad layer cells.
And instead of SLC (single layer) and MLC, they invented pseudo-SLC: A TLC or QLC that can optionally be used as an SLC, obviously with a third or a quarter of the storage, but almost the speed and almost the durability of SLC. Either used as a replacement for SLC, or as a massive cache for TLC or QLC drives.
When I met my SO 10 years ago, she used an old iphone, and said it was telling her it was full, even though she had deleted everything. I told her it probably was making shadow copies of everything, and it was. After some googling, I found that the only way to delete them was funny enough to use linux to connect over usb (windows drivers disallowed something needed), and use a special tool built to access and delete files for that exact reason. This fixed her problem, but she asked what the heck, and I told her it's so the government and hackers could make sure to get a copy of her naked pics in perpetuity. She changed to Android shortly after that.
Apple is a cult, you're either in, or you're not.
"She changed to Android shortly after that" - Perhaps you forgot to use the joke icon? Wikipedia - Android Leverage - A "StartPage" Search: cia startup funding for google -google.com -google.co.uk - Gave many results - Here are 3 from the first pages:-
Medium.com - How the CIA made Google
TheGuardian.com - Google’s Earth: how the tech giant is helping the state spy on us...
I suspect what might be happening is a programming logic bug:
1: Photo synced from local device to cloud storage
2: User deletes photo
3: Photos app database marks photo as deleted
4: Photo deleted from local storage
5: Database entry for that photo is removed
6: Command to delete photo from cloud storage fails
7: Command to delete from cloud storage is never checked for success, and so is never re-tried
When update is done, the photos app reconciles the images on the device on the phone and in the cloud to what it knows in the database. Any additional files that aren't in the database are re-added - hence old "deleted" photos reappearing.
............"deleted" is a little understood weasel word.
(1) The data is still there, but marked as free to be overwritten. Lots of software available for recovery (partial or complete).
(2) The data is still there on some (or many) of those thumb drives you use.
(3) The data is still there, whole and entire, in some (or many) previous backups.
(4) The data is still there (somewhere) because you shared it (on the LAN, by email, in the cloud, Facebook, WhatsApp......)
(5) Unfortunately, some ransomware jerk has hijacked your data..........
(6) Unfortunately, and unbeknown to you, the NSA has some copies somewhere.............
In fact, it's fair to say that the dictionary meaning of "deleted" simply DOES NOT EXIST where computers are concerned.
Quote (William Burroughs): "The paranoid is a person who knows a little of what is going on."
> questionable through local storage since the user must have gone through at least a couple different devices in the last 14 years.
As I type into my 2013 vintage Nexus 7, which is what I believe the young folk would refer to as "my daily driver" (why? It is rarely even in the car, let alone behind the steering wheel! And their music these days!).
It depends. On a hard disk drive - it probably can't be recovered (without specialist equipment and depending how many times you overwrote the file). On flash storage or SSD, there's no guarantee that your dd command actually overwrote the blocks that originally stored your file, they're merely marked as "free" space. So potentially the original file could be recovered by an adversary with enough interest in recovering what you've deleted.
The only way to guarantee file deletion on flash storage is to erase the entire device using something like DD. Or encrypt the filesystem, then delete the decryption key. (provided you didn't store the decryption key on the same device "for convenience")
@ChrisElvidge
You ask: "Can can the original file be recovered?
You need to ask a different question: "From where can the original file be recovered?"
Backups? The Cloud? Your handy thumb drives? ... and so on!
Your original question is only relevant if you know (for certain) that "the original file" only ever existed in a single instance.
If that is not true, then "recovery" is not the problem! In that case the problem is the puzzle: How many copies are there out there?
On modern OS's (certainly using Btrfs, but I am guessing XFS as well) overwriting a file doesn't write to the same blocks. Certainly COW filesystems allocate new blocks for all writes, and decrement the use count for the old blocks. If the use count gets to zero they may, when they get around to it, send a TRIM to the lower level to tell the disk the blocks are no longer being used and it can use them for something else.
If you want data actually overwritten, and removed from the physical media, you need to use very specialist operations. That is one reason I use disk encryption for all my logical volumes - once the key is forgotten the data is really, truly gone. That means that if I stop using a disk (or it fails), I can just throw it away (or sell it, if I want) without worrying about someone reading any of my data. Even if the disk has died and I can't write to it any more.
I've always assumed that deleting photos from your cloud storage merely hides them from your view, but Apple still keep them as training datasets.
Buried in the ts&cs I would expect to find some clause to the effect that Apple have perpetual rights to keep and use anything you upload for "service improvements" or some other legal term. You marking a file for deletion doesn't revoke those particular ts&cs or actually delete the file, just revokes your access to it. Plausible then for an access control bit to be mistakenly flipped by some 15 year old piece of code that everyone forgot about.
Could it be that you transferred a photo into another app, let's say Facebook, then deleted the photo on your phone... later, iOS notices that your Facebook account has photos in it, and it exposes them in the iPhone photo app? Or something like that. Or even, you shared the picture with somebody, and this week they decided to send the picture back to prank you?
Sometimes a user runs out of iClumsy storage, and has to stop the sync on one device, as I’ve had to do, then cleans up the iClumsy storage, and syncing is possible, and then enter a new device, syncing is on by default, bingo, Bob’s your uncle, and you have old NSFW photos and a bit of explaining to do!
It"ll be the icloud thing.
A) yes files that are deleted just have the space marked free. But you have to run an undelete procedure to undelete them, this doesn't happen spontaneously.
B) Everyone is forgetting about TRIM support. This isn't a hard disk, it's flash memory. So in fact deleting files DOESN'T just mark the space free, after you run trim those blocks they read back zeroed out. (This doesn't literally zero out the space either, it marks it available to help the storage wear levelling and keep the storage fast? But as far as the system is concerned it effectively does just that, zeroes the space out.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
