From: Mantis B. T. <no...@bu...> - 2012-06-10 07:19:33
|
The following issue has been UPDATED. ====================================================================== http://bugs.bacula.org/view.php?id=1879 ====================================================================== Reported By: tezza2k1 Assigned To: ====================================================================== Project: bacula Issue ID: 1879 Category: Win32 File Daemon (client) Reproducibility: always Severity: minor Priority: normal Status: acknowledged ====================================================================== Date Submitted: 2012-05-31 13:39 BST Last Modified: 2012-06-10 08:19 BST ====================================================================== Summary: VSS Code interprets a success message as an Error Description: Sometimes, but not always, Windows decides to return an error value from its functions. However this error value is actually saying that it is a success (!!) So unix style checking for any return value representing an error does not work. You get the following error: VSSClientGeneric::Initialize: CreateVssBackupComponents returned 0x80070005. ERR=The operation completed successfully. -------- Personally in my code I check for a return value and then also check the value of GetLastError() . E.g: ret = bind( s, (SOCKADDR *) &dest, sizeof(dest) ); if(ret) { DWORD err = GetLastError(); if(!err) { /* there can be a return value, but no error */ ret = 0; } Steps to Reproduce: Vista 64bit File Daemon Files Set with Enable Vss = yes ====================================================================== ---------------------------------------------------------------------- (0006381) kern (administrator) - 2012-06-10 08:19 http://bugs.bacula.org/view.php?id=1879#c6381 ---------------------------------------------------------------------- Our error messages for VSS (with the exception of the VSS plugin) are not always as complete as they could be. >From what I see, your description could mislead. The "error" message that you show is not an error message but a debug message, and admittedly we don't always have 100% correct debug messages as they are intended for developers. The debug message didn't correctly detect that it was a Windows error, thus the incorrect ERR=, but the non-debug code in fact uses proper Windows checks for return codes. The fact that the debug message was printed indicates that there was indeed an error returned. Bacula knows quite well how to edit Windows error messages and uses proper Windows calls to display them. I have removed the defective debug "ERR=xxx" output and enhanced the more general error message that is printed (not shown in your description). Issue History Date Modified Username Field Change ====================================================================== 2012-05-31 13:39 tezza2k1 New Issue 2012-06-09 11:11 kern Severity major => minor 2012-06-09 11:11 kern Status new => acknowledged 2012-06-10 08:19 kern Note Added: 0006381 2012-06-10 08:19 kern Resolution open => fixed 2012-06-10 08:19 kern Fixed in Version => 5.2.8 ====================================================================== |