Issues exporting to divelogs.de

[Dirk Hohndel]

Moving this to the developer mailing list for now...

On Sun, Oct 25, 2015 at 04:13:58PM +0900, Dirk Hohndel wrote:
> On Sat, Oct 24, 2015 at 03:08:48PM +0300, Benjamin wrote:
> > It happens on both Windows 7 64 bit and Windows 10 64 bit. On both of them,
> > the dialog box closes and nothing happens.
> 
> I can reproduce this behavior. I think it's once again libzip that is
> biting us somehow. Since this is very hard for me to debug the problem I
> a) improved our error handling (exactly the case that hits us here happens
> to not report an error in 4.5.0 but just silently fail
> b) upgraded to the very latest of libzip (1.0beta1)
> and started a new daily build for Windows - it should be available as
> 
> http://subsurface-divelog.org/downloads/daily/subsurface-4.5.0-45-g3b033a85acce.exe
> 
> Internet being what it is here in Palau I was able to do all that and
> trigger the builds on the server, but I'll be in Korea long before a
> download of the daily build would finish.
> 
> So if one of you could test this that would be great.

So the new build still fails. I did some more debugging on Windows (oh the
pain...) and got a bit further.

What actually fails is the zip_close() call (doesn't anybody check errors
anymore?)

What doesn't make sense to me is the error that I get. If I poke directly
at the data structures (since I still can't compile a new Windows binary
locally and downloading from the server is not an option in Palau... but
hey, we're leaving in about 3.5 hours so soon this will be easier to work
on) I get ZIP_ER_RENAME - Renaming temporary file failed: No such file or
directory.

The path used for the tempfile in our code seemed sane
(C:\Users\hohndel\AppData\Local\Temp) but I'm pretty sure that is not the
temporary file that libzip is complaining about. My guess that this is
their internal temporary file that can't be moved and I of course have no
idea what's going on there or how to extract more information.

Lubomir - this does sound vaguely like the problem you fixed before, but
even the Windows 4.5.0 binary was built against a libzip that contained
your fix...

Summary: I'm at a loss what's failing this time. And I'm a bit dismayed
that our code does such a poor job at checking for errors and trying to
give reasonable error messages.

/D