On Thu, Jun 18, 2015 at 03:57:37PM +0200, Jan Mulder wrote: > Below, my first try with the cloud storage.
Thanks for testing this! Things work for me and once I'm at that state I rely on you guys to show me all the ways that the code still breaks... > On my desktop machine. I use (for a long time already) the local git store > as my primary data store for ssrf. Today, I filled the preferences for the > cloud store and received the PIN correctly, and activated the cloud store > (apparently) successfully. Yes, your account shows as verified in the database > Did "save to cloud" and after that "open cloud". > The cloud seems to be populated with my divelog. That is, restarting ssrf, > open cloud manually (did not default to cloud open), and the correct divelog > shows. Excellent. > However. The > https://cloud.subsurface-divelog.org/user/<myemailadress>/dives.html > <https://cloud.subsurface-divelog.org/user/%3Cemail-address%3E/dives.html> > reports (after logging in with correct credentials) a 404. Just to make sure, you did go to https://cloud.subsurface-divelog.org/user/jlmul...@xs4all.nl/dives.html and not to a URL with "<myemailaddress>" in the middle :-) I noticed earlier that the auto-creation of your HTML export triggered a bug and that the exporter would crash. I believe that's fixed now... but I haven't tried accessing the HTML export (again, in general I am planning to try not to use at your data - I actually set it up so that ONLY your credentials allow access that folder from your net - there is no "admin" account that could be (ab-)used to look at other people's data...) > Further, started on a second notebook from scratch. So no local log data, > not even a ssrf installation. Installed the latest master (build myself), > and ran ssrf. Started setting cloud preferences. Authenticated correctly. No > PIN (as expected, because logging in with already activated credentials). Yep - so that works as intended. > Open cloud, and the log shows, so pulled data from the cloud. I see numerous > issues on the notebook after opening the cloud (and at this point unclear to > me whether is is related to the cloud store (or the location management for > example)): > - 1 specific divesite is missing. Apparently, there is some data corruption, > that does not show on the desktop, but does show on the notebook. That's weird. Git is highly unlikely not to notice actual corruption. > - The location list is not filled. Which location list? > - a save to cloud results in error "No user name in git repo, creating > commit failed". Umm. Same bug as in David's report. I need to look at this to see how this is happening - I have never seen this. > In addition. commit 7cf3ebc2f7b6 seems to introduce a SIGSEGV: > strcmp(existing_filename, remote) aborts for remote=0 > > Both desktop and notebook are running Arch Linux. Duh. That's what I get for not using same_string()... I'll fix that right away, thanks for that report. /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
