[Bacula-announce] Win32 restore bug + package tracking

[Kern S. <ke...@si...>]

Hello,

Recently a user reported a problem with Win32
files growing during restore.  This was, in 
deed, a bug. The Cygwin interface was restoring
all files as "text" files thus doing cr/lf
translation. Consquently any non-text file was
thus corrupted.  I didn't see the problem here
because I use environment variables to run Cygwin
in binary mode.

If you have Win32 files that you want to restore,
you should know that the data on your tapes is 
valid, but to properly restore it, you have several
solutions:

1. Ensure that the environment variable CYGWIN 
   contains binmode: i.e.  in c:\autoexec.bat
   have the following:
   
   set CYGWIN=binmode

2. Use the 1.27 File daemon that I have loaded on
   SourceForge in the winbinaries-beta category.
   I have modified the restore command to force binary
   mode (no environment variable necessary).
   This seems to work fine, but I'm a bit uncomfortable
   mixing a 1.26 server with a 1.27 client. As a
   consequence, I would recommend using this client
   only to restore Windows files (up to you to decide).

3. You can mount your disks in binary mode. I mention it,
   but it is sufficiently esoteric that I won't even
   attempt to describe it. See the Cygwin User's 
   Manual if this option interests you. 

The bug is fixed in version 1.27, and I am considering
making a 1.26a release to correct this problem.

==============

To improve security Source Forge has recently dropped
all anonymous monitors. As a consequence, if you have
setup a monitor of a Bacula release but you were not
logged in, you will need to re-establish that monitor.
If you were properly logged in, there is nothing you
need to do. 

Source Forge is recommending that all administrators
tighten up security, but as long as there is no significant
abuse of Bacula, I plan to keep as much open to non-logged
in users as possible.

Best regards,

Kern