Cloud storage and web view

[Dirk Hohndel]

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/jlmulder@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