One of the first principles of disciplined programming is that when you release a new "build" of a product, you increment the build number, so there's no confusion about which one is newer. Acronis appears to have skipped that lesson in Computer Science. There are two CONFLICTING versions of TrueImage Workstation Echo components, both numbered v184.108.40.20653. The two affected files are TrueImage.exe and TrueImageService.exe. One set with that build number is installed with the latest update of Workstation Echo. A different set are offered from download from http://kb.acronis.com/sites/default/files/content/2005/12/1514/failed.to_.read_.html Here's my analysis: TrueImage.exe Installed Version: 220.127.116.1153 Size: 14,369,424 Date: 6/23/2009 (might be local install date) Downloaded Version: 18.104.22.16853 SAME VERSION #! Size: 14,709,226 bytes DIFFERENT SIZES! Date: 7/2/2009 (as unzipped) TrueImageService.exe Installed Version: 22.214.171.12453 Size: 8,715,760 Date: 6/23/2009 (might be local install date) Downloaded Version: 126.96.36.19983 SAME VERSION #! Size: 9,164,933 bytes DIFFERENT SIZES! Date: 7/2/2009 (as unzipped) What are we, who rely on Acronis for a reliable product, borne of a disciplined development process, to think of this kind of thing? A simple "a" after the downloaded build number would make it all so clear! Could it be a simple oversight, a mistake? Yes. But, a robust, disciplined approach to development wouldn't let this kind of oversight or mistake to be released to customers! Are these differences among two files with identical build numbers relevant, or irrelevant, and to whom? Should we who have installed the latest update (8353) update these two later files, too, or are these two files intended for older builds already installed to bring them up to buidl 8353 status? I believe this is indicative of the entire problem with Acronis' development process, and may be an example of a root cause for the persistent problems we report here, version after version!