This is what you said Martin Simmons >>>>>> On Thu, 18 Jan 2007 20:23:38 -0700 (MST), Scott Ruckh said: >> Importance: Normal >> >> I am trying to call a .BAT file using ClientRunBeforeJob. The config >> used >> to work fine before upgrading the Windows FD 2.0.1. >> >> It looks like the syntax in my bacula-dir.conf file is correct. It >> looks >> like the .BAT file is being called, and for some reason there is a >> problem >> with the .BAT file. >> >> Taking Bacula out of the equation, running the .BAT file works without >> any >> problem. >> >> Possibly the environment/context that the Bacula FD runs under is >> different then the user I am using to run the .BAT file. The security >> on >> the actual files appears to be correct for the SYSTEM user, which is >> what >> I believe is the context for the Bacula FD. >> >> Perhaps someone can lend some assistance. >> >> Here is what is reported from Bacula's messages. >> >> ClientRunBeforeJob: run command ""C:/Program Files >> (x86)/Bacula/bin/backup_systemstate.bat"" >> ClientRunBeforeJob: >> ClientRunBeforeJob: C:\WINDOWS\system32>C:\WINDOWS\system32\ntbackup >> backup systemstate /F C:\SystemState\systemstate.bkf >> ClientRunBeforeJob: 'C:\WINDOWS\system32\ntbackup' is not recognized as >> an >> internal or external command, >> ClientRunBeforeJob: operable program or batch file. >> ClientRunBeforeJob: >> ClientRunBeforeJob: C:\WINDOWS\system32>exit 0 >> >> Yes, C:\WINDOWS\system32\ntbackup, does exist and is the correct PATH. > > This is a 64-bit Windows system, right? If so, then I think you are being > hit > by the way that 64-bit Windows hacks file names when running 32-bit > programs. > Basically what happens is that a 32-bit program accessing > C:\WINDOWS\system32 > actually accesses C:\WINDOWS\SysWOW64, which contains files that a 32-bit > Windows installation would provide. The real C:\WINDOWS\system32 contains > 64-bit Windows. > > The problem is that Bacula runs C:\WINDOWS\system32\cmd.exe to execute > your > .BAT file. Because Bacula is a 32-bit program, it ends up runing the > 32-bit > cmd from C:\WINDOWS\SysWOW64\cmd.exe. Then when this cmd runs > C:\WINDOWS\system32\ntbackup, it actually tries to run > C:\WINDOWS\SysWOW64\ntbackup, which doesn't exist. > > To make it work, you'll have to put a copy of > C:\WINDOWS\system32\ntbackup.exe > is some other directory. > > __Martin
Martin is right on! Thanks! Great find as I forgot to mention I was trying to run script on x64 system and originally I was running it on x32. It is still completely insane and does not make sense. Why can't the other command interpreter locate the fully qualified path to the ntbackup executable. Is that other directory structure unavailable when launched from the other cmd.exe interpreter? GRRRR!!! I am not a fan of Windows x64. Everyday I find something new I do not like. Thanks for the help. I hope this thread will educate others with similar situations. Maybe a 64bit Windows bacula FD would help????? Now back to x32 where drivers worked and programs functioned as expected. Scott ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
