[Zubersoft]

As far as the suggestion to prompt the user if the storage location specified in the backup doesn't exist, this is actually quite difficult to do. The reason is that all of the backup restore logic takes place in a background thread. Marshalling data between threads and having to use locks to stop background threads while they wait for the primary thread is doable (I've already had to do this in some places like during file imports when conflicts are detected), but it can get quite messy. The bigger issue is when it comes to selecting the path that the user wants to use. Even if I could hack together all the code to make that work on the tablet, it won't work at all from the companion application as I don't currently have a file browser implemented in it that can get all of the paths on the tablet through the wifi connection.

If I wanted to go this direction, I would probably want to add the storage location as a separate field in the backup file so that I don't have to try to parse it out of the settings files. That way I could open the backup file before initiating the restore, check the validity of the storage location path (if one is specified) and then prompt the user to specify a new path. This would work well on the tablet, but I would still have the issue with the companion app (and I couldn't just have them pick the path on the tablet as switching activities would kill the wifi connection most likely).

For now, I'll just try to handle this as gracefully as I can, and the user will have to move files to a different storage location if they don't like the one that is chosen. What I think I will do is cache the storage location before the restore starts, and if the new one is invalid, I will switch back to what was selected before. That way people can set up the storage location they want if they know the current one won't work on a different device.

Mike