On Friday 03 March 2006 17:08, Martin Simmons wrote:
> >>>>> On Fri, 3 Mar 2006 14:35:42 +0100, Kern Sibbald <kern@...>
> >>>>> said:
> > On Thursday 02 March 2006 22:29, Martin Simmons wrote:
> > > >>>>> On Thu, 2 Mar 2006 21:11:01 +0100, "Florian Daniel Otel"
> > > >>>>> <florian.otel@...> said:
> > > >
> > > > On 3/2/06, Martin Simmons <martin@...> wrote:
> > > > > Cygwin shouldn't be involved here. I know that Kern uses Cygwin to
> > > > > build the fd on Windows, but it can be done from DOS too and the
> > > > > bacula-fd.exe shouldn't depend on Cygwin's dll (if yours does, then
> > > > > that could explain things...).
> > > >
> > > > A quick perusal of the manual and a quick look in the source code
> > > > suggest you might be right. Still, the error codes and the
> > > > "different" behaviour of the code under Windows tend to suggest
> > > > otherwise. Even still, it is a moot point since it doesn't solve the
> > > > problem anyway.
> > >
> > > In fact, I think it is the direct use of the Windows API that prevents
> > > accurate error reporting, because the code assumes errno contains the
> > > error code.
> > This was indeed the case with earlier versions of Bacula, but with more
> > recent versions (sometime during 1.36 if I remember right), the Bacula
> > code should *know* what is a Unix errno and what is a Windows error code.
> > If it is messing up on Windows error statuses, I would like to know. It
> > is rather easy to "forget" to set the Win32 error status correctly, so
> > this kind of problem is quite possible.
> Well, every use of errno is likely to be bogus :-)
No, many are perfectly fine as most of the Unix system calls are reasonably
well simulated and return reasonable errnos.
> The problem here is the code in bnet_open(), which uses errno directly with
Yes, I've already taken a note of this when I saw the trace. This must be one
of those system calls that is not properly simulated. I've noted it for
fixing at some point ...