> > My plan of attack will just be to add some more description about the > > error and go from there (eg is it really an error or some status that is > > being interpreted as an unrecoverable error?)... but any other > > suggestions would be greatly appreciated. > > > > Look at <bacula>/src/win32/stored/mtops.cpp. That is the tape operation > Unix/Win32 compatibility layer, and almost certainly, there is a problem in > that routine somewhere. > > I see in looking at the code that the compatibility layer was not correctly > written. It tries itself to convert from Win32 errors to Unix errnos, and > that is not the best tactic. In fact, when there is an error in some Win32 > API, within Bacula code, you should return with errno = b_errno_win32; > (where b_errno_win32 is set to 1<<29) then the main Bacula routines will know > go and get the *real* Win32 error message (get_last_error) and display it > rather than printing some Unixized conversion of the Win32 error code into a > Unux approximation. > > Just making that change should make the error messages many times better. > Take a look atou how errors are handled (for the most part) in > <bacula>/sys/compat/compat.cpp and you will see what I mean. >
Okay... I've just had a look through. The GetLastError windows command is called in three main places. In the win32_tape_read and _write routines, there is additional parsing of the error done, with bEO[FTD] set accordingly. Should I leave them as-is and just return b_errno_win32 when the error is unknown (default case) or should I set bEO[FTD] accordingly and still return b_errno_win32? The error I am getting is EIO, which is the default case. Hopefully the proper error reporting will tell me what the actual problem is now... It might be a few days before I see the error though. James ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
