copyRootApp wipes existing cache

[aramando]

v1.3.2 (i.e. the fix for #157) seems to have changed the behaviour of the plugin on iOS only so that performing an app root copy replaces the entire destination cache directory for the app rather than just overwriting the copied files. Is this intentional?

Unfortunately this has caused us a big headache because our app is written such that content downloads are merge-synced into a subdirectory of www/, so when we push out app store updates and want the updated binary to use copyRootApp to update all the files in the cache that come from the binary, it is unfortunately removing any content files that have been additionally downloaded by prior OTA content sync operations, meaning that users then have to download all content again.

[macdonst]

@aramando so you push a new app store update but don't include the incremental updates you've done OTA? Just want to make sure I have the use case correct before we make any more changes.

[aramando]

@macdonst We're currently running 2 apps that use this plugin. One of them has all the content bundled in the binary and only downloads OTA updates when newer content is available, but the other is just a shell which only gets any actual content after the user has selected a language on first launch and the appropriate language content package is downloaded. For this latter app, store updates contain any and all incremental updates to the shell that we've published OTA, but no content at all. Therefore we'd really like to be able to do a copyRootApp content sync that can update the running cached code from an updated binary without obliterating anything else that has been downloaded.

[aramando]

@macdonst I've realised that the copy operation that occurs as part of a local sync of the root app files would always have obliterated any existing cache on iOS, it's just that until the introduction of the version check in v1.3.2 that copy operation wasn't even happening if there was an existing cache, so the behaviour was never seen. The problem is basically that NSFileManager doesn't provide a method that can copy and merge with an existing directory, only replace it. That unfortunately places writing a fix for this beyond my iOS skillset.

[imhotep]

@aramando Do you mind trying this fix and letting me know if it works for you?

[aramando]

@imhotep Initial tests look good. I just did a version bump and rebuilt+reinstalled an app and it didn't remove the existing files, but did update them where appropriate.

[macdonst]

@aramando when you get done your testing please let us know and we'll release a new version to npm.

[aramando]

@macdonst Hi Simon, sorry for the massive delay in getting back to you! We've had our app running comfortably on my fork and had forgotten all about this. I've tested again using the copyRootApp branch and it's working fine and correctly updating when the app version is incremented but without removing existing files, so it doesn't mess with our updates. Feel free to merge this into your next version. Thanks.