It's not that simple I'm afraid - I can't know if the files that have already been uploaded to Google Drive were part of a previous sync or were just manually copied there. Also, while I can check to see if a file name exists at a given location (meaning MobileSheetsPro may have copied the file there previously), I can't know if that version of the file actually matches what is on the tablet without doing a hash calculation, which requires scanning through every byte of the file (which would take a considerable amount of time). If I just ignore the potential for the files being different, then sure, I could skip the files. The problem is, what if you create new versions of files on your device or edit existing versions and want those files synchronized to the cloud? While I can (and do) perform simple checks first such as seeing if the file size doesn't match, I can't rely on timestamps because the cloud timestamp won't match what is on the tablet (the hashcodes file was created for this reason). If the size matches, I have to do the hash comparison.
One thing I can do is to try implement a framework for resuming the upload, where I update local files that indicate how far along I am with the sync, along with a copy of the database that will be uploaded. If the sync fails and the user is given the option to try and resume, I could then read those local files, figure out how far along the upload was, and just pick up from there. I'm not sure exactly how much work this would be though. It certainly would require changing a bunch of code to allow a sync to be resumed, which there is no concept of right now. I really need to get the annotations rework done though, so I can't get sidetracked with any other efforts right now.
One thing I can change is I don't currently retry uploading files through Google Drive if the upload attempt fails (as it's supposed to be reliable in nature). I can change this code to attempt 3-5 times, and then if it fails, the sync would fail. This could be enough to get the upload to finish successfully for you. I have personally uploaded 5GB libraries to Google Drive without any issues, so it's certainly possible with the current implementation, but it requires a connection that is never interrupted. If you would like to try a test build that retries the upload multiple times before failing, send me an email at mike@zubersoft.com.
The hashcodes file has 4 entries for every file in the ilbrary:
String that is the path to the file
32-bit integer hash calculated using murmur3_32 from Guava's Hashing class
64-bit long that is the last modified timestamp (should match the last modified timestamp of the file on the Android device)
64-bit long that is the file size
You'll have to make sure that the paths are setup correctly in the database in the cloud. They have to match what MobileSheetsPro is going to expect. I would suggest synchronizing a small library to see exactly how it's populated before trying to write a script to populate it yourself.
Mike
One thing I can do is to try implement a framework for resuming the upload, where I update local files that indicate how far along I am with the sync, along with a copy of the database that will be uploaded. If the sync fails and the user is given the option to try and resume, I could then read those local files, figure out how far along the upload was, and just pick up from there. I'm not sure exactly how much work this would be though. It certainly would require changing a bunch of code to allow a sync to be resumed, which there is no concept of right now. I really need to get the annotations rework done though, so I can't get sidetracked with any other efforts right now.
One thing I can change is I don't currently retry uploading files through Google Drive if the upload attempt fails (as it's supposed to be reliable in nature). I can change this code to attempt 3-5 times, and then if it fails, the sync would fail. This could be enough to get the upload to finish successfully for you. I have personally uploaded 5GB libraries to Google Drive without any issues, so it's certainly possible with the current implementation, but it requires a connection that is never interrupted. If you would like to try a test build that retries the upload multiple times before failing, send me an email at mike@zubersoft.com.
The hashcodes file has 4 entries for every file in the ilbrary:
String that is the path to the file
32-bit integer hash calculated using murmur3_32 from Guava's Hashing class
64-bit long that is the last modified timestamp (should match the last modified timestamp of the file on the Android device)
64-bit long that is the file size
You'll have to make sure that the paths are setup correctly in the database in the cloud. They have to match what MobileSheetsPro is going to expect. I would suggest synchronizing a small library to see exactly how it's populated before trying to write a script to populate it yourself.
Mike