Is an iPhone app's document directory /var/mobile/Documents or /var/mobile/Library/AppName?
Asked Answered
X

7

5

As far as I know (and read everywhere) an application's documents directory should be somewhere in /var/mobile/Library/ on the iPhone but if I'm logging the gotten directory it is /var/mobile/Documents.

I get the directory as follows:

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];

is this a problem if I'm creating a file named Settings.xml in here or is something wrong with my app/etc.?

Information: I've a jailbroken iPhone 4 with iOS 4.2.1 and my app gets installed via Cydia or SSH.


Update

Yeah, but that directory is not really related to my application. For example I am creating a document settings.xml and what if another application uses the same NSDocumentDirectory and the same file name? And yes, I know. Cydia apps got installed into /Applications but there should be a document directory for my app too and not even /var/mobile/Documents. If you take a look at http://thebigboss.org/hosting-repository/submit-your-app/compile-for-cydia-submission the directory should be /var/mobile/Library/ but as I described before, I never get this directory.

Xeric answered 10/1, 2011 at 19:11 Comment(1)
you should have a /var/mobile/Library directory. I have one on my iPhone 3GS running iOS 5.1.1 I did jailbreak with Absinthe.Moynahan
B
2

Using the constant NSDocumentDirectory will in fact get you /var/mobile/Documents when running a jailbreak app. It would be bad policy to dump your app's documents directly in there, even if you think they're named uniquely.

If you look at the contents of the /var/mobile/Library/ folder, you'll see that many apps have their data stored there, including jailbreak apps. It's not clear to me whether there's a handy constant like NSDocumentDirectory that you can use to get that. But, you can always hardcode your source to look for files in @"/var/mobile/Library/APPNAME". It's unlikely that this folder will change (and if it does, it's probably going to break other apps, and is certainly an easy fix to make).

If you look at the document you link to, it does specify:

Appstore app has a Documents folder that is created by the installation process. Jailbroken app does not. It is up to the app to create its own folder. Should you need this type of folder, you must create this with a simple mkdir command in your applicationDidFinishLaunching function. Just add a simple function: mkdir(“/var/mobile/Library/YOURAPPNAME”, 0755); If the folder already exists, no harm done. You want to do this because the install process runs as user root and the app runs as user mobile. If Cydia does this for you then the folder will have the incorrect permissions.

... so you need to create that subdirectory yourself. It won't be there if you don't.

In my experience, writing jailbreak apps simply involves some of these slightly stinky coding practices (hardcoding paths and creating them ourselves) ... it might just be something we have to deal with.

Update: make sure to see Saurik's comment below.

Bullnose answered 24/6, 2011 at 6:10 Comment(2)
One small caveat. /var/mobile/Library/ obviously assumes your app is running as the 'mobile' user, which is the default. Some jailbreak apps need to run as root. If that's truly the case, then you should probably use the folder /var/root/Library/APPNAME. I did that with one of my apps that needed to run as, and save data as, root. The jailbreak guys complained about it a little, but ultimately agreed to have me use that location.Bullnose
FWIW, developers of desktop Mac apps have also (until maybe when inside of the new "stinky" sandboxes forced by the Mac App Store) to deal with this same problem. Also, you should store documents (things the user manipulates) in Documents and state in Library (you will notice no apps have "data" stored in Library in the sense of a "document").Sheers
P
0

Via Cydia apps installed into another folder, that's why you are getting different directory.

Pulmotor answered 10/1, 2011 at 20:11 Comment(0)
L
0

Some Cydia binaries are installed into /private/var/lib/ (like apt-get, openssh, etc). Others are installed into /Applications/ (like Cydia.app, games, etc).

Lian answered 12/1, 2011 at 3:16 Comment(0)
E
0

I am suffering with this issue too... I haven't find out what is happening yet, so I've accepted to work at /var/mobile/Documents. However, I've had to create that directory manually in my device (via ssh or mobile terminal) and set its permissions to 666 [chmod -r 777 /var/mobile/Documents] to let my app save and load files there.

See you!

Exam answered 20/1, 2011 at 11:2 Comment(0)
M
0

What you do is on app start, you check if the file you want in the docs dir exists, and if it doesn't, you copy it there from your read-only application bundle. Each successive time you launch the app, it's there. And, if for some stupid reason apple ever changes it, you don't have to adjust your code, since it's versatile enough to adapt to the change. It'll copy over the original data into the new location (which isn't optimal, but it's better than assuming it's in a static location, which would cause all sorts of confusion amongst your users, or worse: a crash).

Mcmullin answered 23/1, 2011 at 16:4 Comment(0)
H
0

Use your bundle ID as a name, for example com.companyname.appname.Settings.xml. They are rarely the same in different apps. Also you may use UUIDs to name your file and store the UUID that's in the name in the application bundle, but it has its pros and cons: Pro: File never gets overwritten by another app Con: It will be tricky to do such thing.

Hora answered 19/2, 2011 at 10:47 Comment(0)
M
0

All files created by your application will be limited to the app sandbox (e.g. /var/stash/Applications/AppName. When you look for the file, settings.xml, you can get the filePath name using the code example from above.

Storing the file outside your sandbox would not be recommended.

Mo answered 23/2, 2011 at 19:39 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.