Open / Save to cloud on Windows 10

[Dirk Hohndel]

On Sun, Feb 19, 2017 at 02:05:18PM +0700, Jérémie Guichard wrote:
> Hi guys,
> 
> First of all, I'd like to thank you all for the job well done, though many
> improvements and features are to come, subsurface is quite complete and
> useful. I could add that in my case importing logs from dive computer
> actually works better than computer's proprietary software! (There I have
> to sync multiple times before all my logs actually get imported while with
> subsurface it works in one shot and "out of the box"...)

Cool. Which dive computer is that?

> I have several ideas for features and improvements (that I could help
> coding) and am more willing to participate with translation effort, (my
> mother tongue is French).

Awesome. There are two different angles to translations: the application
itself (I think the French translation is fairly complete) which is done
through Transifex, and our website, where we have a slighly odd setup to
translate things through a github repository and pull request for that
(https://github.com/Subsurface-divelog/subsurface-website)

> I'd like to deal with one issue that is pretty
> important for me since I want to use the mobile app too, the "cloud
> storage".
> 
> In the current state, on my Windows 10 machine, whenever I try to: "Open
> cloud storage" in end up with a "Error connecting to Subsurface cloud
> storage". Same thing if I log some dives and try to "Save to cloud
> storage". Using an Ubuntu virtual machine, the same operations succeeds.
> (So no issue with credentials or unregistered account)

I assume this is with our official 4.6.1 installer, downloaded from our
website?

> Starting the app with logging options (--win32console --verbose -v -v), I
> get such messages (for the "Open Cloud Storage")
> 
> git_remote_repo: accessing
> https://cloud.subsurface-divelog.org//git/xxxxx@xxx.xxx
> git storage: 0 % ( start git interaction )
> git storage: create_local_repo
> Cloud storage: checking connection to cloud server
> Checking cloud connection...
> git storage: 0 % ( waited 1 sec for cloud connetion )
> Cloud storage: successfully checked connection to cloud server
> git storage: 0 % ( successfully checked cloud connection )
> git storage: calling git_clone()
> *git storage: returned from git_clone() with error -4*
> 
> According to libgit2 git2/errors.h this is
>  GIT_EEXISTS = -4, /**< Object exists preventing operation */
> 
> This lead me to navigate
> to  C:\Users\xxxx\AppData\Roaming\Subsurface\cloudstorage and delete the
> contained git repo.
> At that point I can actually get my cloud stored dives locally. If I try
> the "Open cloud storage" again the original error comes again unless I
> delete the git repo again.
> 
> Now if I edit or add a dive, and "Save to cloud storage", same error.
> I delete the git repo, then "Save to cloud storage"

Yikes. That's weird.

> git_remote_repo: accessing
> https://cloud.subsurface-divelog.org//git/xxxxx@xxx.xxx
> git storage: 0 % ( start git interaction )
> git storage: create_local_repo
> Cloud storage: checking connection to cloud server
> Checking cloud connection...
> git storage: 0 % ( waited 1 sec for cloud connetion )
> Cloud storage: successfully checked connection to cloud server
> git storage: 0 % ( successfully checked cloud connection )
> git storage: calling git_clone()
> delete proxy setting
> cloud certificate considered valid, forcing it valid
> cloud certificate considered valid, forcing it valid
> cloud certificate considered valid, forcing it valid
> git storage: returned from git_clone() with error 0
> git storage: do git save
> git storage: 0 % ( start git save )
> git storage: 0 % ( start create git tree )
> git storage: 0 % ( start saving dives )
> git storage: 0 % ( done creating git tree )
> git storage, write git tree
> existing filename
> https://cloud.subsurface-divelog.org//git/xxxxx@xxx.xxx[xxxxx@xxx.xxx]
> 
> Then I open again (with a deletion of local repo in between) and nothing
> was actually saved to cloud.

Since we always first save to the local repo and then sync the repo to the
cloud, your data might have gotten lost there somehow.

> The same operations (excluding deletion of local repo) works under Ubuntu.
> 
> My best guess is that checking the presence of local repo somehow fails and
> fresh clone is always attempted (resulting in the GIT_EEXISTS error since
> the folder is already present). Further investigation would need deeper
> code investigation. This issue do not seem to be reported in github so I
> preferred to contact you before creating the ticket...

This is the first time that we have seen this type of report - and we have
several thousand users on Windows (not sure how many use the cloud
storage). I can happily load from and store to the cloud storage when
running Subsurface in a Windows VM.

Let's ask some simple questions. You have excluded your user name from the
path and replaced it with xxxx (not unreasonable). Is that user name "all
ASCII" or are there possibly some fun characters mixed in? I try to
regularly test that we didn't break anything with non-ASCII paths, but I'm
not 100% sure that I've done that for the last few builds... I would
assume that someone else would have run into this in the month since we
release 4.6, but who knows.

If that's not it, is there anything else that's odd about your setup? I
assume you can delete the directory without any special permissions (in
other words, there isn't some weird permission / ACL problem going on)?

/D