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 <d...@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/xx...@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/xx...@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/xx...@xxx.xxx[xx...@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 >
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface