IOS5 may delete local file storage-Caches is not secure

Transferred from: http://blog.163.com/ray_jun/blog/static/1670536422011101225132544/

Source: http://superman474.blog.163.com/blog/static/120661462011101115811199/

Local file storage for iOS 5 Marco (the developer of Instapaper) wrote a very good post explaining the related issues, interested students can read his article and then read the following.

There are also a number of issues related to the Apple Developer Forum:

Save files securely?

How do I persist files within the cache folder?

Where do I save my files if I want them to be saved permanently and not synced with itunes?

Cloud Backup for ICloud takes up a lot of space?

Some confusion

In the discussion at the Apple Developer Forum, the following puzzling questions were summed up:

1. About the meaning of the cache and temporary file directories
2. Update modification of Apple development documentation
3. Application Audit denied
4. What files will be backed up by itunes and icloud
5. The mechanism of IOS 5 changes

Let's discuss it one by one:

About the meaning of the cache and temporary file directories

If you have an OS X or UNIX development background, it's easy to understand Apple's position that there is no guarantee of how long the data will persist in both directories.

The Temporary Files directory (TMP directory) and the root directory (ROOT/TMP) in the application sandbox are actually not the same, but they do not need to be treated differently.

In the past, if you had never observed that files were deleted in these directories, that would not be guaranteed later. This is a common rule, especially when this change is consistent with the development document description.

Update modification of Apple development documentation

Until June 2011, the official development document on <application_home>/documents said:

"Use this directory to store user documents and application data files"

This usage is quite clear. While iOS 5 changed the use of the documents directory without giving any appropriate alternatives, it's no wonder that the developer was unhappy.

And the <application_home>/library/caches of the word is:

"Use this directory to write proprietary support files for any application so that you can keep them intact when the application starts or when the application is updated."

Your application is typically responsible for adding and removing these files, and in some cases, recreating the required files because itunes will delete the files saved here in recovery mode. ”

The meaning of this passage is very unclear. I read it to the effect that Apple made a fundamental change in iOS 5, which makes it very contradictory to see the explanation. But if you look closely at the words "usually" ("generally") and "Can recreate" ("able to re-create"), when Apple warns you that the files in your app are out of spec, you'll see where they need to be improved.

Instructions for the iOS Data storage instruction manual (iOS Storage Guidelines):

"To try to make sure that your files are backed up efficiently, be sure to save your app data based on the following guidelines:

1. Only those user-generated documents and other data, or those that cannot be rebuilt by your application, should be kept in the <application_home>/documents directory. These data files will be automatically backed up via icloud.

2. Data that can be re-downloaded or recreated should be stored in the <application_home>/library/caches directory. You can put database cache files or downloadable content such as magazines, newspapers, map application data, etc. into the cache directory (Caches directory)

3, the temporary need for data should be stored in the <application_home>/tmp directory. Although these files are not backed up into icloud, remember to delete them as soon as you no longer need them so that they do not continue to waste the user's device storage space. ”

In fact, many newspapers, magazines and maps of the application of pure purpose is to display content offline, if we temporarily ignore this, then the above guidance is very clear, can refer to.

Application Audit denied

Developers are now reporting that apps that keep any/few/large amounts of data in the document directory are being rejected for review.

Application auditing is unlikely to be exhaustive, such as figuring out which files are stored in which directories, which files are generated by the user, and which data can be re-downloaded or recreated. In some developers ' reports, they explained to the application Review department how the application saved the data, how to follow the guidelines, and then their application was passed.

What files will be backed up by itunes and icloud

All data in your app's home directory will be backed up in addition to:

1. The compiled app package file (. App)
2. Files in the <application_home>/tmp directory
3. Files in the <application_home>/library/caches directory

These are very clear in the comments of iOS data Storage guidelines and Michael Jurewitz, which are in the instruction manual for the storage of the iphone.

Other development documents also make it clear that files in the application support directory are also backed up by itunes (assuming icloud will). Some developers in the discussion think that saving files within the application Support directory is more secure (more durable) than the caches directory. I think the application audit department will reject those applications that store large amounts of data in the application Support directory, which is the same as the strict audit in the document directory, thanks to the lack of storage space in icloud.

What else is worth noticing?

There is no more directory where your app can save files and can:

1. Not backed up by itunes or icloud
2. Will not be cleared due to space constraints

It's obvious that it's too late to do that on iOS 5.0. But if enough developers argue, let Apple know that they really need to keep this feature in their apps, maybe the next version will be added. Tip: Submit a file bug report.

What do developers have to do?

If you are currently saving files in the documents directory

Your app will certainly continue to work in iOS 5, and your users may complain that a lot of data has been backed up to icloud. (see below for details)

However, when you update your app, you may be denied approval because too much data is stored in the documents directory.

If you are taking or considering saving files in the caches directory,

Make sure that your app can still be handled properly in the caches directory where your saved files suddenly disappear. One way to do this is to include the source URL (the original path or address) of all the files stored in the caches directory in a single list. This allows the application to verify that the file is still present by traversing the manifest.

If any of the files disappear, you can display a dialog box to apologize to the user, explain why and ask if you want to download the file again. If the device is offline, you can only apologize to the user and then tell the user "you're done."

There are many more complex situations than these two, such as: Which of the data can be used. You need to decide what data to display, how much to display, etc.

A developer speaking on the Apple Forum user use case, I find it interesting: His application is to show the map for the pilot. If he puts a downloadable map into the caches directory, then if the map data is suddenly deleted by iOS 5, then the plane is still in the sky, it may be tragic. A dialog box that allows pilots to re-download map data will definitely hurt his feelings deeply.

Migrating data that already exists

If you follow the new rules of IOS 5 or icloud to update the app and store the files in the Caches directory, you may need to transfer the files that have been stored in the document to Caches. I'm sure the App review section won't test this because they don't have an old version of your data. But it's a good thing to do.

Remember not to consume too many resources for file transfer in the main thread of the application when it starts. This will cause your app to be killed by the startup time Monitor.

Early warning

When the app is running, you can tell the user if the device is in a low-space situation. While this does not prevent the file from being erased, it can at least make the user aware of the problem.

I'm not sure what the minimum amount of disk space is before the erase program in iOS 5 is running, and I suspect Apple will give you specifics. If you have any results of your own experiment, be sure to add a comment below.

Let Apple realize it's a big problem.

Submit a file bug report.

What can users do?

Until now, apps that kept a lot of data in the directory were a headache for backups because itunes took a long time to back them up. This is especially annoying when there are many files that must be backed up.

With icloud backup, users may not want to use their poor 5GB storage space (or spend extra space) to back up data that they don't think is important. An individual app can turn off icloud backup. Settings can be easily found in app settings: ICloud > Storage and Backup > Manage storage > Backup. In the list of backup options, each app can choose whether to back up. It may not be easy for your users to find the settings and you may need to send an email to guide them.

These are my understanding, although I haven't had time to test whether turning off icloud backup has an impact on itunes backup. But for those users who no longer have to connect to the computer to sync, the app that turns off icloud backup as described above does not have backup data.

The following function keeps a path file free of icloud backup

-(BOOL) Addskipbackupattributetoitematurl: (Nsurl *) URL
{
if (&nsurlisexcludedfrombackupkey = = nil) {//IOS <= 5.0.1
Const char* FilePath = [[URL path] filesystemrepresentation];

Const char* attrname = "Com.apple.MobileBackup";
u_int8_t attrValue = 1;

int result = Setxattr (FilePath, Attrname, &attrvalue, sizeof (AttrValue), 0, 0);
return result = = 0;
} else {//IOS >= 5.1


NSLog (@ "%d", [URL setresourcevalue:[nsnumber Numberwithbool:yes] Forkey:nsurlisexcludedfrombackupkey Error:nil]);
return [URL setresourcevalue:[nsnumber Numberwithbool:yes] Forkey:nsurlisexcludedfrombackupkey Error:nil];
}
}


My experience: When the application exposes the following error message, the contents of your caches folder may be deleted automatically. 

//when space is lowMalloc:stack logs being written into/Private/var/mobile/containers/data/application/819156cf-c8b8-43ff-bf63-0eabf59cb655/tmp/stack-logs.1373. 15a3000.esvideo.aqpqel.indexesvideo (1373,0X39C8A9DC) malloc:recording malloc and VM allocation stacks to diskusingStandard Recorderesvideo (1373,0X39C8A9DC) malloc:process1338No longer exists, stack logs deleted from/Private/var/mobile/containers/data/application/819156cf-c8b8-43ff-bf63-0eabf59cb655/tmp/stack-logs.1338.1508000. Esvideo.tYs7hy.index -- ,- +  the: A:47.000esvideo[1373:382143] Irate verbose logging enabled.

Or

//application crashes when space is lowMalloc:unable to write to stack logging file/Private/var/mobile/containers/data/application/f20f8c6c-9709-490a-9dda-e294c1ef3b50/tmp/stack-logs.1234.1549000. Esvideo.mNh6B0.index (No space left on device) Esvideo (1234,0X39C8A9DC) malloc:stack logging disabled due to previous errors. -- ,- +  -: $:06.950esvideo[1234:373855] Unable to copy temp file. Error:error Domain=nscocoaerrordomain code= + "The operation couldn ' t be completed. (Cocoa error.)"userinfo=0x19e68e10{nssourcefilepatherrorkey=/Private/var/mobile/containers/data/application/f20f8c6c-9709-490a-9dda-e294c1ef3b50/library/caches/com.apple.nsurlsessiond/downloads/com.easou.esvideo/cfnetworkdownload_ Bhoozh.tmp, nsuserstringvariant=(Copy), Nsfilepath=/Private/var/mobile/containers/data/application/f20f8c6c-9709-490a-9dda-e294c1ef3b50/library/caches/com.apple.nsurlsessiond/downloads/com.easou.esvideo/cfnetworkdownload_ Bhoozh.tmp, nsdestinationfilepath=/var/mobile/containers/data/application/f20f8c6c-9709-490a-9dda-e294c1ef3b50/library/caches/download/video/naruto 605_554cd72c0cf29e8153e068a6/naruto 605_ 554cd72c0cf29e8153e068a6_0, nsunderlyingerror=0x19e69b50 "The operation couldn ' t be completed. Result too large"}

IOS5 may delete local file storage-Caches is not secure