<1455738179.3877554.524148514.7D001732@...> <CAGiAgVe-vEpn44zwYoaOkZP8XdriQeKWvHgQDLshaLh63kkG+A@...> <CAGiAgVcxja1QpjcYHz-Rf+fjyDYhbMLXiq5q4_akYoe7QSE+uw@...> <CAGiAgVdoVrJqET5xrFDkQGYhQLhkqW3R2cESeR95MN5r0y=Sjg@...>
Message-ID: <c4b5bb69acdafd107020994e6bea6583@...>
X-Sender: mark@...
User-Agent: RoundCube Webmail/0.2

A quick note: I wasn't able to finish reviewing your code this weekend,
and I am afraid I - probably - don't have time nor energy until next
weekend.

I noticed that you used `mark` (and `reset`) to check if you already
reached end-of-stream, unfortunately not all streams support marking. This
needs to be addressed in some way, for example check `markSupported`, and
if false wrap in a `BufferedInputStream` or instead of using `mark`, we
could use a `PusbackInputStream` (so the read can be 'pushed back'), or
maybe we need to do this differently (eg reading farther ahead).

I went digging in the Firebird code to see how the remote backup/restore
worked, and I got a bit lost. I also looked at the .net provider and I am
considering whether we should divide this in two classes as well (one for
backup and one for restore), just like is done in the .net provider.

If you haven't yet done so, use the formatting definition in
build/formatting, as I noticed your code is using tabs instead of 4 spaces.
If you already did, let me know which one you used (intellij or eclipse),
as it could mean something is wrong in the formatting definition.

Mark

On Sun, 21 Feb 2016 22:07:03 +0200, "Ivan Arabadzhiev intelrullz@...
[Firebird-Java]" <Firebird-Java@yahoogroups.com> wrote:

> Hi again,
> Code is quite stable but I did encounter a glitch while testing - I have

a

> .fbk, created by x64 Windows Firebird, which will throw my restore in an
> endless loop with a linux server (restores fine to Windows). I do see a
> difference in the fbk, depending on which server created it and in that
> specific case the server stops requesting more info 2 bytes before EOF.
> Just to make things even more fun, every now and again it manages to
> restore ... which I find a bit strange.
> The good news is every server I tested can restore its own backups (with
> any JVM on the client side).
> The other good news is that fbsvcmgr doesn't have that problem so I'm
> looking into how things are handled over there.

Was it a transportable or non-transportable backup?

Mark