06-20-2012 09:17 PM
I've set up some assets in bar-descriptor.xml, some of which are files (in the root) and some of which are folders (which have files and other subfolders within them).
If I inspect 'BAR Packages' using the IDE everything seems to look OK, ie:
AppName.bar + native - File 1
- File 2
- File 3
- File 4
From code, I can call fopen() on the files in the root (File 1 and File 2 in the above example) and read them without problem. However, any attempt to check for the existence of the folder with stat() or attempt to iterate it with opendir()/readdir() fails completely, as if it doesn't exist.
In fact, I've tried iterating the contents of the root app/native folder with opendir()/readdir() in order to see what's there and that fails too (opendir() returns NULL).
I'm beginning to think that directory operations on app/native simply aren't possible. Am I missing something?
Solved! Go to Solution.
06-20-2012 09:20 PM
Probably you need to read this https://developer.blackberry.com/native/documentat
Also note that to get from the current directory, when your app is running, to the files in the native folder, you'd need to reference them under the "app" symlink, thus "app/native/yourfiles".
06-20-2012 10:00 PM
Thanks, I've been over that page you linked several times before and I'm reasonably certain I've got this right because I can open any file in the root OK. I'm prepending all paths with the path returned by getcwd() to get the current working directory, so in slight pseudocode:
fopen(<cwd>/app/native/File 1) works OK
fopen(<cwd>/app/native/Folder/File 3) fails
An example of the full path I'm supplying to fopen would be something like:
I suppose a better question is : is anyone successfully using nested directories under app/native?
If so, I'm doing something wrong.
06-20-2012 11:40 PM
06-21-2012 10:25 AM
Thanks for all your help everyone, after some messing around I've managed to solve my problem(s)!
I changed my code to use a relative path (app/native) rather than constructing an absolute path based upon the working directory. This didn't fix anything but helped make paths easier to deal with in general (note : the PlayWavFileMakefile sample should probably be changed to use the relative method, since this is where I copied it from).
Next, I changed the .bar file to a .zip to inspect the contents and used the IDE's system information perspective to inspect my app's mounted volume at runtime. Being new to this platform, I hadn't realised that you could do either of these things - everything checked out OK, but this gave me full confidence that the problem was most likely in my code and not to do with the OS or my bar packaging.
Finally I found I had two problems:
- The first was to do with a silly mistake when using the QNX-specific dirent_extra_stat structure to work out if a file item was a file or a directory during iteration of the directory tree.
- The second problem was difficult to find but easy to solve. I found that I could iterate directories using opendir()/readdir() successfully, but only on the main thread. Most of my file access is on a worker thread however, and this failed. By inspecting the file system's errno on failure I found that it was reporting out of memory. I realised that I needed to use a larger stack size when creating the thread, and everything then worked OK. Interestingly, I was only using a small stack of 4K which worked fine on WIndows, OS X, iOS and Android but I had to increase it to 32K for the PlayBook. Most likely, QNX is using the stack for a lot of its working variables here and the other platforms favour the heap.
I hope this may help someone else in future.
06-22-2012 10:31 AM