The first application update, loss of user data (stored in the Documents directory)

Question

My first update for the app was last night, and I received a complaint that the update caused the user data to disappear (some of them). I was able to reproduce the problem, but I can not understand why.

In the Documents folder, I saved one key file that tells me the "name" of all user files and their files (full path). Then all user files are also in the Documents directory.

When the update occurs, the key file still exists (at least I think this is because the data is displayed on the first screen of the application - the applications completely shut down and restart after the update, right?), But when the user tries to go to the actual files, there is no data, and any new data that the user enters is never saved.

It acts in exactly the same way as when debugging, when I accidentally used an invalid file name (with incorrect characters in it) - it was never saved. But with the update, these files were saved correctly in the old version, but somehow they do not work in the new version.

This is my first application and my first update, and I don’t understand at all here. I pulled the application out of sale at the moment (I did not know that you can’t just go back to the old version! Yikes!) And I will deeply appreciate any ideas on where / how to look for the problem and how to write a GOOD update that will not lose data. (For now, all I have found is to "save the data in the Documents directory, which I already did.)

I have an original application saved in his own project, and I can go back and work with it again. I copied this entire directory when I started working on the update, and I am wondering if this could somehow be the problem? I changed the name of the directory in which all Xcode files are stored, and used the Project> Rename function. Could this have such an effect?

The application (both the original and the update) works on 4.2 and higher, if that matters.

Decision:

I believe that I understood this problem. As I said at the beginning of my question, I saved the FULL path of user files in my key files. Apparently, after the update, it is not guaranteed that the full path will not be the same (I'm sure it is registered somewhere somewhere, but I did not come across it).

So, the custom HAD files were moved to the new Documents directory, but I searched for them in the old absolute path, that is, not in my sandbox.

Fixed by putting a loop in the didFinishLaunching application to pull out the offending file of the file paths (THAT, I always searched locally and it still worked) and chopped them off only to the NAMES file. The path to the documents must be found and added programmatically whenever file operations are performed.

For me, it was really useful for me that there is no way to return to the previous binary in the store, because reinstalling the original version would not fix the user’s problem, but I would believe that it was, at least initially. I would like to have a way to decline UPDATES, but still allow new purchases (since the problem did not affect new purchases). This is probably not a common enough situation to guarantee this.

Answer 1

Just shed some light on this for online passers-by. Yes, the OP answered his question at the very end. You should never store absolute URLs for files in the document directory, and this can lead to data loss. This is due to the fact that when updating the application, changing its version # in the .plist file, iOS creates a new directory for this application with a different hexadecimal name. Now your absolute url is referencing the wrong location and will not return the correct file.

You can see this on your own computer before deploying it to your device by going to

~ / Library / Application Support / iPhone Simulator / * ios_version * / Applications /

There you will see folders with names like:

6AA4B05C-8A38-4469-B7BE-5EA7E9712510 CB43C5F3-D720-49C3-87D4-EBE93FFD428B

Inside these folders will be a standard file system layout for iOS applications. i.e.

Documents TMP Library YourApp.app

Going through the entire URL, you will see something like

~ / Library / Application Support / iPhone Simulator / * ios_version * / Applications / 6AA4B05C-8A38-4469-B7BE-5EA7E9712510 / Documents / MyVeryImportantUserData.txt

However, when updating the application, the new application URL will look like this:

~ / Library / Application Support / iPhone Simulator / * ios_version * / Applications / CB43C5F3-D720-49C3-87D4-EBE93FFD428B / Documents / MyVeryImportantUserData.txt

which is empty.

Instead, you should always make a dynamic link, saving only the file path after you get the path prefix to the document catalog file.

/** Returns the path to the application Documents directory. */ - (NSString *)applicationDocumentsDirectory { return [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject]; } 

On the original poster, you could save your lost user data by releasing a new update in which you changed your code to get an absolute URL and trim everything through part of the documents in a row. You can then prefix the file path with the corresponding directory URL and the application would detect the data.

Answer 2

Both questionnaires and the first answer were useful for figuring out what exactly was going on.

Therefore, based on my observations, I realized that there was (which seems to be) renaming folders in the path leading to the Documents folder. This led me to a solution in which I save only file name files and create a utility class to capture the fullPath current line , which was saved and is now stored in the current Documents folder after updating the application:

 #import "StringUtils.h" @implementation StringUtils + (NSString *)getFullDocumentUrl:(NSString *)fileName { return [NSString stringWithFormat:@"%@/%@",[self applicationDocumentsDirectory],fileName]; } + (NSString *)applicationDocumentsDirectory { return [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject]; } @end 

Answer 3

I ran into the same problem. Below is an example code to correct your file names by iterating through files in the document directory and replacing file path information, leaving the file names. Before executing the last line to change the file names, I would recommend using NSLog to make sure that this is exactly what you want in your updated name.

  NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString *documentsPath = [paths objectAtIndex:0]; //Get the docs directory NSFileManager *fm = [NSFileManager defaultManager]; NSArray *filenames = [fm contentsOfDirectoryAtPath:documentsPath error:nil]; //Match on the filepath leading up to docs directory NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"^/\\S*Documents/" options:NSRegularExpressionCaseInsensitive error:nil]; for (NSString *fileName in filenames) { NSRange fullLength = NSMakeRange(0, [fileName length]); //swap out the prepended directory structure with an empty string NSString *updatedFileName = [regex stringByReplacingMatchesInString:fileName options:0 range:fullLength withTemplate:@""]; NSString *currentName = [NSString stringWithFormat:@"%@/%@",documentsPath,fileName]; NSString *updatedName = [NSString stringWithFormat:@"%@/%@",documentsPath,updatedFileName]; [fm moveItemAtPath:currentName toPath:updatedName error:nil]; }