Open / Save to cloud on Windows 10

Sun Feb 19 02:32:15 PST 2017

Hey Dirk,

Thanks for the fast reply!

Computer is Suunto Zoop. With Suunto DM5 I have to sync multiple times
before all logs are synced...

I'll take a look into translations, I normally use English interfaces, just
switched to french to see the status, seems pretty complete though some
translations could be improved. I guess I'm a bit late for the 4.6.2...
Website seems to be a bit more behind...

Indeed I used official 4.6.1 installer.

No specific ACLs on the directory. But my user name do contains the french
"é". So I created a new user with only ASCII chars, cloud storage features
Open/Save are working fine. You have found the issue, yepee!!!

How should I proceed? ticket, fix, etc. I must admit I'm not there yet with
setting up dev env, I only got to build from source yesterday in the ubuntu
virtual machine... (btw I had a short attempt to do so using linux
subsystem for windows but did not succeed...)

Cheers,

Jeremie

2017-02-19 14:41 GMT+07:00 Dirk Hohndel <dirk at hohndel.org>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170219/97ab5fb0/attachment-0001.html>