Native Development

[dposluns]

Hi there,

FIrst of all, there seems to be an error in the documentation here: https://developer.blackberry.com/native/documentation/com.qnx.doc.native_sdk.devguide/com.qnx.doc.na... - it claims that the temporary directory is named "temp", but in the filesystem it appears to be "tmp".

Second of all, any files I write to the tmp directory appear to get deleted as soon as the application exits. This is very inconvenient for me. I want to use the tmp directory for persistent caching of data between launches... I'm fine if it needs to be purged by the system on occasion for arbitrary reasons, and I don't want it to be backed up as permanent application data, but having it purged every single execution is pretty much useless to me.

Is there a way to change this behaviour? Or another directory that's recommended for use for caching/temporary files but not quite as aggressively purged as tmp?

Thanks,

Dan.

[mzex]

Hi

Why you want to use tmp dir? If you need to store some files , store them into app folder, they will be accessible only to your app.

[dposluns]

Well, the reason for using the tmp directory instead of your app directory is twofold:

1. For files that you don't need backed up. A web browser, for example, might want to cache several hundred megabytes of web pages downloaded from the internet, but it would be wasteful and pointless to have those files backed up.

2. For files that you won't necessarily miss if they're purged. Again, with the web browser, it's very convenient to have the cached files around, but if the system needs to wipe them to make space it's not a problem to download them again.

Dan.

[peter9477]

I think there are some legitimate use cases hinted at here, or imaginable if one thinks about this for a while. Sounds like a good item for a feature request, which you can make in the issue tracker, referencing this thread.

I could see either them removing the aggressive deletion of ./tmp folder contents that the documentation guarantees, or adding a new ./cache folder with different semantics. The system would allow data to persist there across invocations of the app, except if the system needed to free up some flash storage space. Persistence wouldn't be guaranteed, but at least immediate removal would also not be guaranteed.

This would also allow the system to avoid backing it up, though probably the reason ./tmp is deleted right away now is because the backup process is "dumb" and just blindly archives all contents under /accounts/1000/appdata.

It's been suggested there may be a way of storing data in a ./shared subfolder but marking it (special folder name?) so it's not included in the backups, but that's suboptimal in at least two major ways. For one thing, if the owning app is deleted, the data sticks around forever. For another thing, the data is exposed rather than being protected in the app's sandbox folder with the usual protection.

In any case, you do not, as far as I know, have any good option for doing this right now. You either use ./tmp and get no caching benefits across app invocations, or you use ./data and whatever space you consume in caching is unavailable to the user as long as your app is installed, even if your app is never run again.

[dposluns]

Well that's disappointing. Thanks for clearing it up though. Would love to hear the official opinion from somebody on the RIM side of things. As far as I'm concerned, this is a pretty fundamental OS feature that's missing.

[peter9477]

Unless I've made a mistake in interpreting the behaviour, you are unlikely to hear an "official opinion" here. We almost never do. That's why I suggested the "feature request" approach in Jira, as it's one of the few direct channels we have to RIM personnel who would be able to give the idea the attention it deserves.

[smcveigh]

I've fired off some inquiries to the backup folks to see if we can find a solution that works for you.

I don't think we'll be able to get you a "pooled" cache directory where it only gets emptied when other apps need the space, as that is a nontrivial system feature.  However, if I could get you support for something like an ".ignore" convention for folders in appdata/ during backups would that be a good start?

Obviously, the amount of space your app consumes or needs to consume is going to be dependent on what sort of app you have, and as a result, pruning that data should really be the responsibility of your app.  You imply that this is a fundamental OS feature, but I'm not familiar with any comparable feature in other operating systems.  If you could direct me to one, I'd be glad to learn about it.

Cheers,

Sean

[smcveigh]

Try putting your cache files in the "logs" directory.  I am told that this folder is not part of backups.  You will still need to do your own pruning.

I will pursue a more appropriate solution further, but will end up requiring backing from the highest levels to modify the appdata/ directory structure to add a new folder such as "cache".

Cheers,

Sean

[dposluns]

Well, iOS and Android both have such a directory.

iOS has Library/Caches: http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammin...

Anroid has getCacheDir(): http://developer.android.com/guide/topics/data/data-storage.html

Both of these may be purged by the operating system but are not automatically, and are ignored by backup systems.

Dan.

[smcveigh]

Thanks for the info.  I will use it to argue for this use case.  The rules are a bit hand-wavy as to how such a cache dir operates on those systems, so much so that the tmp/ behaviour would also fall under that umbrella presently.

In any event.. the logs/ directory is persistent storage, and is not backed up, so it sort of suits your needs, however I have been cautioned that putting hundreds of MB in there may anger the system service that handles app crashes, as it may be making copies of these logs as part of crash reports.  So be careful in the meantime.

Cheers,

Sean