Aller au contenu principal

Acronis, and it's BUG LADEN Software

Thread needs solution

Three intrinsic problems with Acronis B&R 11 Build 17318:

Pre/Post Scripts:

1. CALL statements within pre/post scripts MUST include a full path to the called script, even if in the same folder! This means scripts can no longer be "standard," (but must be customized for each install, unless you always install to the same path) because there is no "logical search" for the called file name.  CMD.exe CALL statements, are SUPPOSED to search first in the local folder for the named file, then every path in the PATH environment variable, before reporting failure to find the named script file.

2. Script files must now terminate execution with "exit 0"; the simple exit (i.e., no error code) is no longer allowed; the specification of no error return number--e.g., "exit"--is now treated the same as "unspecified fatal error."  This is a departure from prior TrueImage products, which have not, here-to-fore, required the zero; Acronis have now made the " 0" mandatory on each terminal "exit" statement. This appears to be a violation of customary .bat and .cmd conventions for most programmers writing scripts.

3. It is unclear if ".cmd" files are acceptable, or must have ".bat" extension.  Requiring the latter means several features in ".cmd" files are disabled.  The dialog for "Pre/Post" configuration lists only (under "File(s) of type") ".exe, .com, .bat" as the options (unless you select "all files"). This, in turn, suggests that ".cmd" is not an acceptable extension, which is either true (in which case it is a radical departure from prior TrueImage products), or false (in which case, it would be more helpful if Acronis would add ".cmd" to the list of default options for executables).

MMS.exe Fails to Start

After an uninstall of B&R10, including the Acronis "uninstall cleanup" program, then install of fresh B&R11, the "mms.exe" service fails to run, reporting that "one or more dependencies" failed to start. In fact, all services on which "mms.exe" depends are running; the problem is that the credentials entered for the service (<computer>\Administrator and <password>

) are changed by the installer so that the password I supplied is not the password that was recorded for the service (it shows more characters than in my known password). Changing the password fixed the problem. This seems to be another defect/bug in the code.

Idiotic GUI

1. Create a Backup Plan in the Navigation window, scheduled to start at, say, 8:30 am. Save your work.
2. Go back and change the time meridian to, say, 8:30 pm. Save your work.
3. Return to the Backup Plan in the Navigation window and it STILL shows the "Next Scheduled Start" as 8:30 am!
4. Go back and check the Backup Plan and confirm that your scheduled next start is 8:30 pm.

It is consistent and persistent programming errors and failures in Quality Assurance testing at Acronis that make me so )(*@$& frustrated. 

That, and the fact that Acronis support schedules a call back from someone they claim will know something about these issues...and they never call back. This is how software companies end up, like Borland, et. al. They may not be dead, but I'm sure that both of their customers are very happy.

0 Users found this helpful

I understand your pain. It looks like you're not using managed vaults and/or deduplication. If you did your post would be longer and more violent :) For the script problems you could try (as a workaround) to start the command interpreter by itself and use system environment variables. so for a command script in C:\programdata\myscripts use

"%COMSPEC%" "%ALLUSERSPROFILE%\myscripts\script.cmd"

this will expand to (on Vista/7)

"c:\windows\system32\cmd.exe" "c:\programdata\myscripts\script.cmd"

of course this depends on B&R expanding environment variables correctly. I must admit i didn't check that...