Clear Archive Bit?

Thread needs solution
truwrikodrorowrelupicugojestutroclulachosaswunuhospikigawakijosaswenomaruclojeueclikaspedrubewidebrisubrohutrurifruuagothunugekedrumucisiuobrobrecrupeslapuswosluprothethibakaslechurathikucli
Beginner
Beiträge: 1
Kommentare: 0

It appears that doing a drive image backup does not affect the archive bit. Is there some way of doing this so that subsequent incremental backups will not backup files that are unchanged since the drive image backup. I tried adding the commend attrib -a c:\*.* /s as a command to be executed at the conclusion of the backup, but this did not succeed, perhaps because one needs to run the DOS command prompt window with administrator privileges in order to run the command. (Don't know, just speculating that was the problem.)

At any rate, does anyone know of a way to do this automatically from within True Image ver 11?

Sa, 01/09/2010 - 23:07
0 Users found this helpful
truwrikodrorowrelupicugojestutroclulachosaswunuhospikigawakijosaswenomaruclojeueclikaspedrubewidebrisubrohutrurifruuagothunugekedrumucisiuobrobrecrupeslapuswosluprothethibakaslechurathikucli
Regular Poster
Beiträge: 11
Kommentare: 229

nice question but the premise of it is not correct.
The archive bit is NOT used at all.

the archive bit can be thwarted manually and in some cases not changed even though an application changed the file.

because the archive bit is not 100 accurate acronis does not use it all.
instead a much more "secure" algorithm is used.

Acronis calculates a value for the file
that calculated hash value includes every aspect of the file's data contents as well as its physical locations of every file fragment on disk.

To acronis, a file is considered has having been changed if the hash value is different.
It doesn't matter why the hash is different just that it is different.

This method works 100% of the time even if its change was just your defrag program moving the file around.

This is one reason why some people complain their incr backup files are so huge.
most often the underlying cause is those users have a defrag program which is running 24/7 in the background.
the "solution" is run a defrag in one huge swoop (periodicaly (weekly?monthly?quarterly?)
and then take a backup after the defrag.
versus a defragging little bit all day 27/7 and having a daily backup track the changes.

hope this helps.

So, 01/10/2010 - 02:19
  • Anmelden, um Kommentare verfassen zu können
truwrikodrorowrelupicugojestutroclulachosaswunuhospikigawakijosaswenomaruclojeueclikaspedrubewidebrisubrohutrurifruuagothunugekedrumucisiuobrobrecrupeslapuswosluprothethibakaslechurathikucli
Forum Star
Beiträge: 45
Kommentare: 4263

Quite a few other imaging programs detect changes by comparing the data. However, as far as I know, only B&R 10 offers this option and it's disabled by default. Instead, TI determines if a change was made by comparing the file size and the date.

---

This is from the B&R 10 manual:

To speed up the backup process, the program determines whether a file has changed or not by the file size and the date/time when the file was last modified. Disabling this feature will make the program compare the entire file contents to those stored in the archive.

---

If the "Fast" detection method wasn't used, TI would take just as long as a Full image to create an Incremental or Differential image because all used sectors would need to be read and compared.

There was a thread on Wilders about this. If you edited a sector of a file directly using a disk editor, TI wouldn't detect the change and wouldn't include the changed file in the Incremental/Differential backup.

So, 01/10/2010 - 07:54
  • Anmelden, um Kommentare verfassen zu können