Open Radar

 
As soon as <PRODUCT NAME> (appstore version REDACTED) is launched on iOS13 Beta, all files disappear. The document packages remain, but all the files within the document packages are gone. We confirmed with using iCloud.com. This has happened to at least 3 users so far.

User reported: "One day she went to <USE APP> and they are simply not there. I walked her through trying to restore one of them via the Versions feature but again, there are no versions, they are just all gone. I asked her if she recently added any devices to the mix and she said that she updated one of her devices to the iOS 13 beta around the same time." A ZIP archive of her entire <PRODUCT_NAME> Documents folder is attached.

The files are gone even from her other iOS 12 devices.  The one iOS13 device connected to iCloud and killed all her files -- and that synced to the other devices. And somehow, the destruction of her documents cannot be undone via either file revisions or the "recently deleted" feature of iCloud. With dread, we've concluded internally: " her <DOCUMENTS> may indeed be gone."

Q: "when she logs into iCloud.com and goes to iCloud Drive, there’s no <PRODUCT_NAME> folder?"  A: "She said there is but all the <DOCUMENTS> have 0kb"

Note: <PRODUCT_NAME> never does anything with all files across all projects. Even the per-project commands are only performed by-demand of a user action. So not likely a bug in our code. We simply do not operate across all documents.  Also, note, "they’re not even files. They are package folders."  That's why the sketches show up in iCloud Drive as 0kb -- the package is still there, but all the document contents from within the document are gone.

Another clue -- in Files.app, all the documents have a " 2" appended to the filename (see "mysterious_2.jpeg", attached).  As if iCloud attempted to duplicate the files but only did a shallow copy, and did not copy the package contents, and then deleted the originals.  The same goes when looking in iCloud (see "mysterious_2_icloud.png") Note: the " 2" might be a red herring, we also noticed: "At first I thought it was odd that they all have ” 2" at the end, but so do the ones in my iCloud Drive, so I guess that’s a thing (though bears looking into — I’d think that would only happen when making a copy of a document, but that’s clearly not the case)."

Other users have reported data loss, e.g. https://twitter.com/hsousa/status/1142107851420254208 "Hey @<REDACTED> do you only save a <DOCUMENT> on exit? Last night I <USED PRODUCT> on my iPad (iPadOS 13 :scream:) and closed it (without closing the app). This morning I think it restarted during the night (#betalife) and my <DOCUMENT> was gone."

Note: We've had other issues with iCloud which I'll report in additional feedback documents, but in case it's a useful clue to your investigation, here is a brief summary of other problems we're encountering -- in the off chance that this file-deletion problem is a result of some kind of cascading failure:

* Trying to open a document there produces an error: `Error Domain=NSCocoaErrorDomain Code=256 "The file "2018-12-14 14.22.06 2.<REDACTED>" couldn't be opened." UserInfo={NSFilePath=/private/var/mobile/Library/Mobile Documents/iCloud~REDACTED/Documents/REDACTED/2018-12-14 14.22.06 2.REDACTED, NSUnderlyingError=0x2811bf660 {Error Domain=NSPOSIXErrorDomain Code=11 "Resource deadlock avoided"}}`
* `FileManager.default.isUbiquitousItem` is returning `false` for files that are on iCloud
* NSURLThumbnailDictionaryItem const NSThumbnail1024x1024SizeKey is non functional

My completely wild speculation: Has the NSUbiquitousContainerSupportedFolderLevels “One” setting changed how it works in the presence of packages? They are technically folders, but you could create nested structure inside them below the normal one level of subfolder in the past. If Apple made a change where they stopped allowing that, and don’t provide access to anything below the “one level” of folder depth, then the result of this could be that the contents of the packages would disappear as we’re seeing here.