Bacula version 1.32c released

Hello,

I've just posted Bacula version 1.32c source code
and Windows binaries to Source Forge, and have
asked Scott to prepare the rpms, so they should
be available shortly.

This version is totally compatible with any
previous 1.32 -- that is as long as you have
1.32, 1.32a, or 1.32b installed, you need
not upgrade everything at the same time

There are two main features in this version:
1. I "finally" have the gnome-console working
   on Gnome 2.0 (or higher), and Gnome 1.4
   is also supported (in a different source 
   directory). The ./configure select the correct
   one.

2. I'm 95% sure I have solved the elusive Windows
   "Packet size too big" problem. As a consequence,
   if you are using any Windows Clients you will
   definitely want to upgrade.

Most Significant Changes since 1.32b
- Implemented a RunAfterFailedJob record in the Job resource.
- Implemented "delete job" command in the Console.
- Gnome 2.0 console compiles and works.
- Implemented VerifyJob record in the Job resource
  that tells Verify which job to verify (JobId not required)
- First cut Verify Disk to Catalog
- Fix "status dir" to examine all run commands in Schedule.
- Close unused file descriptors in bpipe.c
- There is now a patch for FreeBSD 4.8 pthreads that
  fixes the problems of data loss at the end of a tape.
  Please see:
  <bacula-source>/platforms/freebsd/pthreads-fix.txt
- Fixed (I think) the elusive Windows "packet too big" bug.
- Added %v to RunBefore/After editing codes. It edits in
  a list of Volumes used for the job (not tested).
 
If you want more details, please see the ChangeLog.

Best regards,

Kern

==== Windows "Packet too big" bug =======

For those of you who are interested in the Windows bug,
solving it started with Alexander Schremmer reporting
that turning on debug code in apcupsd (UPS control
program) caused apcupsd to shutdown his system because
the debug output was being sent to his serial port. Not
too nice, but it didn't seem very likely that debug
output was going to the serial port and who really
cares about seeing debug code under Windows?  
Nevertheless, he stuck with it and discovered that 
the serial port was opened on file descriptor
1 (stdout). This is because Windows being very intelligent
(sarcasm) doesn't bother to open stdin, stdout,
and stderr for a Windowing program. As a consequence,
the first files that are opened will be allocated to 
those descriptors. Which means that if the program
writes debug code to stdout, it will go straight
to the serial port.

It then dawned on me that the same thing was happening
on Bacula, namely that the communicates sockets were
being opened on stdin, stdout, and stderr, and that
if there is a stray error message printed, it would
blast the comm socket giving the packet too big 
error.

The solution is simple: very early in the program, open
/dev/null. If the fd is greater than 2, close it and
continue.  If the fd is less to or equal to 2, 
keep it open -- do the same for fd 0 and 1. So no
sockets will be opened on stdin, stdout, or stderr,
and any code that uses them will simply go to
/dev/null. Rather amusing, isn't it?

======= end Windows bug =======







-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/