ATI 11 Error backing up movie files

I am doing a data backup of one of my folders. When it gets to a movie file (.wmv, .flv, .mov) I get an error. This never happened on my previous version ATI 9, and I'd really hate to go back because I like some of the new features of 11, however, I do create movie files and need to get them backed up. If I exclude all movie files, the backup runs successfully.

A full disk backup ran successfully with no errors.

Here's the text of the error log:


event code="1" id="5" level="4" message="Failed to backup file or folder 'C:\Documents and Settings\Personal\My Documents\Personal\Burning_Desire.wmv'.
Error reading the file. (0x40001)
Tag = 0x61F1883FE50B0A30
Snapshot read failed. (0x10C45A)
Tag = 0x14181C22EF45AD23
The parameter is incorrect (0xFFF0)
code = 80070057)
Tag = 0xBD28FDBD64EDB8AF: Retry/Ignore/Cancel" module="4" time="1216748201"

event code="1" id="6" level="2" message="Failed to backup file or folder 'C:\Documents and Settings\Personal\My Documents\Personal\Burning_Desire.wmv'.
Error reading the file. (0x40001)
Tag = 0x61F1883FE50B0A30
Snapshot read failed. (0x10C45A)
Tag = 0x14181C22EF45AD23
The parameter is incorrect (0xFFF0)
code = 80070057)
Tag = 0xBD28FDBD64EDB8AF: Retry/Ignore/Cancel: User replied: Cancel" module="4" time="1216748481"

event code="1" id="7" level="4" message="Error reading the file. (0x40001)
Tag = 0x61F1883FE50B0A30
Snapshot read failed. (0x10C45A)
Tag = 0x14181C22EF45AD23
The parameter is incorrect (0xFFF0)
code = 80070057)
Tag = 0xBD28FDBD64EDB8AF" module="4" time="1216748482"

 

Did you try "chkdsk C: /F"?

Edit:
Possibly "chkdsk C: /F /R" corrects the error but try first without "/R".

 

Also, is it always the same file?
If so, rename it with an odd extension like .xyz, then exclude that file type and see what happens.

 

I think it doesn't help.
Let me explain:
The fullbackup saves the data byte by byte. It is not neccessary that there is a correct byte.
And that happens sector for sector. The image program doesn't check that it is wrong. When you restore the image the file is wrong further more but nobody notice that.

The data-backup works in annother way: The image program reads file by file. When there is a wrong byte the file is corrupted. The program notice it and an error appears.

Then it helps to repair the file via chkdsk.

But: Let's wait for jlanda.

 

My point –
Is it that particular file that is the problem or .wmv (etc.) in general and that file just happens to be the first one encountered.
How to tell? Remove that file from the equation.
Depending on the disk size, a rename is much quicker than chkdsk.

 

Yes, I agree.

BTW: I overlooked your "...then exclude that file type ..."

 

Here's the thing, it's ANY movie file, and it doesn't matter what the name is or extension, it could be .wmv, .mov, or .flv (flash extension.) All are functional, non-corrupt files as I can view them just fine. I just reinstalled ATI workstation 9.1 that I originally had. There wasn't a problem backing up those files with the older program, so the problem isn't my files, it's the ATI 11 that's having the trouble.

I did one backup set with ATI 11 that bypassed all movie files (set exclusions for those extensions) and it worked fine, but then after restarting the computer, I found that none of the exclusions were saved and I would have to re-exclude the movie files again the next time the task ran. I got fed up and installed the older version before I lost something important waiting for this to get fixed possibly in a newer release or bug patch.

However, I would still like to see this issue get addressed since I may want to put it on another computer at some point, as long as it works. I'm surprised because I've used ATI in multiple versions (for myself and for clients) for a few years now and never ran into trouble until now.

 

What build of TI 11 are you using? The latest is 8101. It does fix some problems, so if you aren't using it, download it and see if it has the same problem.

Obviously, this should not be a problem.

Have you run CHKDSK /R on this drive? Click the Windows Start button, and type in the Run command area:

CHKDSK C: /R

I have assumed that the files are stored on the C: partition. When you reboot, CHKDSK will run and check the partition for errors and correct them. This can take quite a while for a large partition, perhaps one hour.

 

Some other things you might want to check.

What compression factor are you using, does it disappear if you set it to none, bearing in mind that all the extensions except RAW have some form of compression?

How deep down in your directory/folder structure are your movie files, does it work if you move one of them perhaps to the root dicrectory?

It might be that in fixing something, Acronis have changed the way TI behaves in other ways, inadvertently or otherwise.

Once the cause is identified, then there may be some answer, or another fix required

Colin

 

Good questions from bogdy (see above).

Additional questions:
1. How large are the movie files?
2. What filesystem has your target device (NTFS, FAT32, ...)?


BTW:
I suggest to register at Acronis homepage and open an issue. You can relate to this thread.

 

Did a chkdsk beforehand (usually do a full drive cleanup/maintenance on big backup days) and that wasn't a problem. I did think of the compression selection and can't remember if I switched that to none as I usually set it to high (since the backup file is then transferred online.) I'll have to try it on another station and see if that does the trick as I can't remember if I ever did test it.

I did download the newest version to see if that would do the trick, but alas, no. I did notice other odd behaviors I didn't have in the older version, like if I select to only back up certain folders inside of a folder, ATI 11 insists on backing up the entire parent folder. That of course is a problem for the smaller backups meant to transfer online, so perhaps they still need to make a few tweaks to it.

I'll try the compression thing and report my findings in case anyone else runs into the problem.