Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

dropbox sync without wifi + sync again with wifi = lose all data

edited October 2015 in General Posts: 143

Hello guys,

I was wondering whether it is possible to retrieve saveImage() and io.write() data after losing them through the dropbox sync crash. The text and image data I have lost is VERY important for some work I am doing at the moment.

The step by step method of reproducing this bug : First create an image and string, then use saveImage() and io.write() to save the image and string. Then turn off internet connection, then dropbox sync. The app will crash at this point. Then turn on the internet connection, then dropbox sync again. The syncing will appear to work but after checking dropbox, there are no files there.

Now I have been doing a bit of research and it seems the files might still be there on the ipad somewhere but after looking through iexplorer, I cannot find them. Is there a way to retrieve them now?

Would it be a good idea to save the data locally to the ipad documents as a secondary backup (even if it is difficult to retrieve it later)?

Cheers

Comments

  • edited October 2015 Posts: 143

    @simeon @dave1707 hi guys, do you have any idea how I can retrieve those lost files? There might be a place where they get saved before syncing that I cannot see?

  • Posts: 2,015

    I'm sure you've already done this, but check your remote dropbox. What file extensions do the files have? (the asset picker only shows certain extensions, eg .txt for text files)

  • edited October 2015 Posts: 143

    @yojimbo2000 Hello Yep ive checked all dropboxes, ive used iexplorer to look inside all the ipads files.

    I was hoping someone could point me to the hidden directories where all data go before it gets synced, or where all the old data is located, or some way to force a resync to dropbox. The files cant be deleted just after it syncs to dropbox, can it?

  • edited October 2015 Posts: 143

    @yojimbo2000 @simeon I have looked through all codea directories and have concluded that the pre-sync files are not stored in there. So it must be elsewhere on the ipad temp files. Is this correct?

    Ah after some more investigation, the pre-sync files are stored in the drop.assetpacks folder. This can be found on the ipad using a directory like ifunbox, but cannot be seen on the typical dropbox app until syncing is done. So i assume these files will be deleted once syncing happens, that means that the old files are most likely irretrievable.

  • Posts: 2,015

    You should probably pm Simeon. Out of curiosity, how come you're using io.write and not saveText?

  • i was using this function from some old code

    function writeFile(fileName, data)
    
        --local file = os.getenv("HOME").."/Documents/" .. fileName
        local file = os.getenv("HOME") .. "/Documents/Dropbox.assetpack/" .. fileName
        wFd, err = io.open(file, "w")
        if wFd == nil then
            --error("\n\nError creating/editing file " .. fileName .. "\n\nError: " .. err)
        end
        wFd:write(data)
        wFd:close()
    end
    

    It seems to do what i need it to so never needed to change, is savetext better?

  • Posts: 2,015

    It does all that in one line.

  • oh i see, hah will use it next time!

  • Posts: 2,015

    But it only supports the extension .txt (and you omit the extension from the file name when using readText and saveText)

    So you do need to use the method you give above for other extensions.

    I would probably avoid trying to write if the open command fails (I'm sure Codea would just stop with an error, but just to be safe):

    function writeFile(fileName, data)
    
        --local file = os.getenv("HOME").."/Documents/" .. fileName
        local file = os.getenv("HOME") .. "/Documents/Dropbox.assetpack/" .. fileName
        wFd, err = io.open(file, "w")
        if wFd == nil then
            --error("\n\nError creating/editing file " .. fileName .. "\n\nError: " .. err)
        else --new
            wFd:write(data)
        end
        wFd:close()
    end
    
  • SimeonSimeon Admin Mod
    edited October 2015 Posts: 4,504

    @yojimbo2000 saveText should support "txt", "json", "js", "php", "html", "css", "text", "xml", "vs", "fs", "frag", "vert", "notes", "yaml"

    I'll look into this further now

  • edited October 2015 Posts: 2,015

    Cool! Any chance you could add extensions for text-based 3D file formats? .obj .mtl

    Part of the issue seems to be that readText and saveText (like readImage and saveImage) truncate the extension. Also that file extensions other than txt don't show up in the asset picker.

  • SimeonSimeon Admin Mod
    Posts: 4,504

    @yojimbo2000 will do relating to the 3D model formats. Any others?

    The formats I listed above should show in the asset picker, if they are not then that's a bug I'll need to fix.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @Simeon - while we're talking file formats (and not wishing to distract from the question above), is there any chance of offering a built in OBJ file read function in a future version? @yojimbo2000 already has code for this, which might just need some testing for robustness (which we can do for you).

  • SimeonSimeon Admin Mod
    Posts: 4,504

    @Ignatz yes, I'd really like for the mesh() function to present a 3D-model picker, and have native 3D model support.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @yojimbo2000 - perhaps we can run a few models through your code to make sure it is robust enough for general use. I'll do some testing if you link me to your code.

  • Posts: 2,015

    Ok, I'll try to post it later today.

  • edited October 2015 Posts: 2,015

    @Simeon my apologies, the extensions you listed above do show in the asset picker ( @archistudent so you could use files with .json extensions with ReadText and saveText, I misinformed you).

    Regarding other text-based 3D file formats, there's directX (extension .x) and collada (.dae) and Stanford (.ply).

    @Simeon, if you're looking at the saveText code, there's also the issue where you can't delete text assets with saveText nil: https://bitbucket.org/TwoLivesLeft/core/issues/370/savetext-name-nil-does-not-delete-text

  • Thanks everybody, I will use saveText in my next build!

    Just some clarification for myself, what is the best local save and read method for apps that is intended for appstore? obviously this method cannot rely on codea or dropbox anymore, thus the methods ive used here is not viable. The method ideally will allow you to keep data cached on the local ipad, and in the event the app crashes, the data can be retrieved by the app once it is restarted again. I am sure lots of other apps like news apps use this local storage for their articles.

  • Posts: 2,015

    You can use ReadText certainly with the Dropbox folder in Xcode projects. The folder becomes an asset folder in your Xcode project (it's no longer connected to your actual Dropbox). Presumably saveText works too? Check the recent thread though on issues with Xcode 7, if you haven't already done so.

  • oh interesting, that would be a good way to save and load local data then?

  • Posts: 2,015

    I haven't tried saving in an Xcode project, but loading certainly works.

  • edited November 2015 Posts: 8

    Hi, I experience this problem too. I have to run my app with wifi off (to remove latencies introduced by network access on the ipad). I then have to turn wifi on, then do a Dropbox sync. If I (or the students running this project) forget to turn wifi on before Dropbox syncing there will be much gnashing of teeth when the collected data vanishes!

    Is there any roadmap for a fix for this one? It doesn't seem to be listed in the fixes section for Codea 2.3.2.

  • @sebjames @simeon

    I've done a few test to find out what currently happens in that situation.

    First, when codea attempt to sync dropbox.assets without wifi, it crashes. (At this stage the files are still there and can be retrieve using another software that can access the directories).

    Next, when codea attempts to sync dropbox.assets with wifi turn on, codea is tricked into believing it should not have those files in the assets folder since whatever list it was using to keep track has been 'corrupted' by the crash, so it goes on and deletes the files.

Sign In or Register to comment.