File I/O root path inside of codea apps

Is there any way with the release version of Codea to find the root path for raw file I/O? I have assets I want to read that I have placed in the documents folder that are NOT images…specifically, I am reading X3D xml files. I know I can use Dropbox or any external website, but I’d like to be able to package and load locally.

This code below does not work. I tried /Documents, ./Documents and Documents:, all to no avail. And I already know that getenv(" HOME") doesn’t work on this version of (jailed iPad) Codea.

    local fname = "../Documents/Dodecahedron.x3d"
    local info_file =,"r")
    assert(info_file~=nil,"Could not open "..fname)
    local contents = ""
    for lin in io.lines(fname) do
        contents = contents..lin.."\
    print (contents)

I’m interested in the answer to this. I kind of remember @Simeon mentioning that the io.* function works - but I could be wrong.

The other approach would be to convert the files to strings and use saveProjectData().

Found this:

@aciolino, did you get this to work? I just tried to read and parse a file from the Dropbox.spritepack folder, but it failed. Now I read in another thread, that it is no longer possible with iOS 6 (which I have installed) to use io.getenv. Is there any way around? What I tried to do:

    local home = io.getenv("HOME")
    local file ="/Documents/Dropbox.spritepack/codea.ply", "r")
    local res = file:read("*all")

What I would like to do maybe in the future of Codea:

    local file ="Dropbox:codea.ply", "r")
    local res = file:read("*all")

BTW, I’m reading PLY files, seems we are both try to visualize 3D :slight_smile: I need models for my game.

The root path for Codea seems to currently be “/var”. This is on my jailbroken ipad - if I try to write to “tmp/hello”, I get data in “/var/tmp/hello”.

A future release (the next, I expect) should have os.getenv available by default, without you having to hack it. I also expect the default working directory to be Codea’s Document’s directory, and I wouldn’t be surprised to be jailed there.

So - the code you have above, or very close to it, is correct - or will be, soon.

Being jailed to the documents/MyProgram directory would be fine for me, as i finally build my app with xcode, so everything is together with the lua code in one directory… also easier to handle with my svn :slight_smile: if the dropbox could then also refer to the program directory where the lua codes lie, then i would have everything in one place : lua, gfx and other data. just one directory for the whole project.

I’d be fine being jailed to /var! I just want to get to my data…and I’m also going to XCode when done, so at the end of the day it won’t matter, as long as we can save to and read from a directory.

Personally, I’m fine using the API features, except that they don’t really allow binary data to be persisted. When it comes to simple things such as high scores, or simple string data, I’m going to stick with the API as it is simple; saveGlobalData() is pretty darned simple!.

After I get some additionsl stuff done, I’ll verify that a jailed iPad iOS 6 can write to /var.

I think I’d prefer being jailed to the Documents directory; and I suspect Apple will require it. Being able to poke data outside of that means being able to poke (and copy and otherwise manipulate) other apps data - and as much as it’s a pain, it’s also nice knowing some rogue app isn’t going to poke around in my other app’s data. There are mechanisms for moving data from app to app (“Open in…”) - and Codea at least supports importing (or did? with .codea. Hmm. One wonders if Apple would allow Codea to be an “Open In…” target for text files… hmmmmmmmm…)