----- Original Message -----
Sent: Monday, October 27, 2008 3:59
PM
Subject: Vista 64 - Bacula 2.4.2, VSS and
symlink/junction issues
Hello, Bacula Users. I apologize for adding
yet another thread to this topic. I've seen a number of threads that
make mention of these Vista problems, and they seem to drop off sometime
around mid-2007. Yet, for me the issues persist, so I'm perplexed.
If someone has a link to the definitive answer(s) to these issues, I'd
appreciate your reply.
For the client in question, I am using Backula
version 2.4.2 on Vista Ultimate 64-bit. I've been using Bacula for a while now, and have come to enjoy its
reliability and configurability. Unfortunately, I'm in an environment
where I must also support Windows, including Microsoft's latest proof that
they don't understand upward compatibility: Vista. Bacula seems to
handle the various Linux flavors in the network, and even the XP client seems
quite reliable. However, with Vista (especially Vista 64-bit) we are
seeing a significant set of problems.
The most costly issue (for me) is the monkey
wrench that I started to see surface in this forum about a year and a half
ago, where the "junctions" (provided by M$ to point directories to legacy
directory names) cause the FD to bail out with messages like:
27-Oct 02:05 m1330-fd JobId 414: Could
not open directory c:/Users/dennis/AppData/Local/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data/Application
Data/Application Data/Application Data/Application Data: ERR=The name of the
file cannot be resolved by the system.
Not long after this message began to appear on
internet, I saw a message (22-Jun-2007) from Kern Sibbald saying that the
problem should be solved with a few lines of code. I've not found much
of consequence on this topic in the sixteen months since that time, but the
problem persists (at least for me). Have I missed some key version of
the software, or pointer designed to help get past this error? (It is a
big deal in spite of the following observation by Mr. Sibbald: "However, if I am not mistaken, it
*is* backing up these junctions, and will
probably restore them correctly...") For me, my
backups fail consistently with the
following:
27-Oct 02:17 m1330-fd JobId 414: Fatal error:
Too many errors.
27-Oct 02:17 luke-sd JobId 414: Job write elapsed time =
00:11:54, Transfer rate = 7.516 M
bytes/second
By the way, exclusions do not seem to help
resolve this (or maybe I don't know the proper trick). I have the
following in my fileset, but to no avail:
FileSet {
Name =
"VistaSet"
Enable VSS = yes
Include
{
Options {
WildDir =
"c:/Users/*/Application Data/Application Data"
<snip>
Exclude =
Yes
}
File =
"c:/Users/dennis/AppData/"
File =
"c:/pers-data/"
<snip>
Options
{
signature =
MD5
compression =
GZIP
_onefs_ =
no
}
}
}
In spite of this exclusion, I still receive
(thousands of) messages like the example from
above.
- - - - - - - - - - - -
The other issue is VSS. I've seen threads
that indicate this issue was solved long ago (cannot find an example at the
moment though - sorry)... but the most recent mention I find of this is from
August 8 this year, when Kern Sibbald indicated that a new build was ready -
but then the trail runs cold. Is there any hope of regaining VSS support
on 64-bit Vista?
Thank you for your time!!!
Dennis