Synch Dirs/Compare by Content: Bug in "compare by conte

handil · Post by *handil » 2011-02-18, 07:15 UTC

Hello,

when i synchronize directories (menu: Commands/Synchronize Dirs) with checked option "by content", then the most files are marked as "Unequal files".

Now, when i compare these files with the windows commandline program "comp" they are absolutly identical. Also when i compare these files, in file by file manner, with the menu function "Files/Compare by Content", these files are absolutly identical too.

The files comes from trueimage, with a size larger than 10 GB. it does not happens with smaller files. Its proofed with files up to 800 MB. but in some circumstances it happens too. There is one file, that ist equal if i compare it with comp.exe, but sometimes when i compare it with single file compare by content or with the synchronize dirs function, it is fitful unequal.

I think there is a bug in the compare function. It's not a reliable situation, when i copy files with total commander and its looks like an unequality of files after the copy action.

greetings

handil

PS: Sorry for my englisch, but if you find a mistake, take and keep it...

MVV · Post by *MVV » 2011-02-18, 07:30 UTC

handil, are dates of compared files identical? If not, do you have sync option 'ignore dates' checked?

handil · Post by *handil » 2011-02-18, 07:48 UTC

Hello MVV,

yes, the dates of the files are absolute identical.

Before i use the synch function, i have copied the files from one harddisk to the other harddisk. First time with the windows copy function and next time with the total commander copy function. After every copy action i have made a synch/compare run with the "Command/Synchonize Dirs" command (Option "by Content" checked). The effect is, unequal files. Without the option "by Content" the files are equal, with the option "by Content" this issue happens.

Additional information: the virus protection is, while the compare command runs, disabled!

The compare run begins, after some minutes or bytes, there is a break (within a file compare action), and all files down are marked as unequal.

handil

Balderstrom · Post by *Balderstrom » 2011-02-18, 09:36 UTC

What happens when you double click on the newly unequal files to compare them ?

Does the compare-tool find any differences?

handil · Post by *handil » 2011-02-18, 10:07 UTC

It starts the compare again, after some seconds the window of differences is opend, and i get the message:

Not enough memory, search aborted!

The two files are DIFFERENT!

Thats all.....

When i compare these files with comp.exe, there are equal.

What's going on?

MVV · Post by *MVV » 2011-02-18, 14:01 UTC

Are you sure you comparing same files using sync tool and comp/tc comp?

handil · Post by *handil » 2011-02-18, 14:22 UTC

Yes, i'm extremly sure, there are the same files, with the same names, the same dates, the same times, the same sizes, and exactly the same content.

But for now, i have tested the same action at annother computer with windows 7 professional (x64), and there, the camparison is absolutly ok! Within tc and comp.exe!

Now i'm test it on a Windows XP Professional Tablet PC Edition with Service Pack 3, and then i will see if its ok or not.

At this time, i think there is no bug in tc, but maybe i have a problem with my server (windows home server; based on SBS 2003). Or, if the next test fail, an problem with OS's based on Windows XP and/or Server 2003.

We will see.... (it later)

Post by *Hacker » 2011-02-18, 22:05 UTC

handil,
You could also try and create MD5 checksums for both files to check if TC sees them as equal but specifically the compare function does not.

Roman

handil · Post by *handil » 2011-02-21, 06:58 UTC

Sorry for the lag, but it needs a lot of time to check all options.

Now, i have sureness. only the one computer with windows home server on it, make problems with tc and compare actions via synchonize dirs and other functions. Why, i don't know.

Now i have made MD5 checksum files for a selection of 15 zip-files with each of a size of round 25 GB. After the sixth file i've got the error "can't read file xyz", and the action stops. I marked the remaining files and start the action again, but the failed file was not read, and the other remaining files was also failed, without any action. After the error occurs, no zip file can be opened and no action can performed.

When i check the zip-files with the 7zip test function, they are all ok!

The next step was to restart tc, but the error happens again.

Next, i restart the computer, and try it again to create the MD5 checksum files for the remaining zip-files. It starts, and the checksum file generation runs without any failure. After creating the checksum files, i copied the MD5-files to same zip-files on the second harddisk and start the action "verify checksums". After there, all files where ok while checking the checksum.

Then i go back to the first files (see the first posting), generate MD5 checksum files for it, i copied these MD5-files to same files on the second harddisk, test the checksum , and most files where ok. I restart tc and test the failed files again, and they are ok too.

I don't know what happens, but on this computer it is not reliable to use tc for more than copy files. No comparison, no checksum generation and check.

I give up. Thank you for your help.

handil

Post by *white » 2011-02-21, 09:04 UTC

It looks like you are running out of memory. Maybe you should check resources while testing.

handil · Post by *handil » 2011-02-21, 09:10 UTC

Sorry, but the system (windows home server 2003 32 bit) has 4 GB of memory, and the taskmanager tells me, that only 1,5 GB of memory is used, at the whole time of actions. It can't be an bottleneck in the memory system.

handil · Post by *handil » 2011-02-21, 11:47 UTC

In Meantime, i have made an cross test with another tool (like tc) to compare files. The tool, NexusFile (http://xiles.net/downloads/#NexusFile), i have used, can compare all files (true Image image files and the 15 zip-files) on bit-level without any problem, and all files are absolutly identical.

Now i think, there is a problem with tc on windows home server 2003 with an amount of 4 GB on memory, and perhaps in my configuration. Where and why, i can't say it.

Post by *ghisler(Author) » 2011-02-21, 15:27 UTC

It looks like you are running out of file handles. A file handle is needed to open a file. TC closes all files directly after comparing, but I have seen such a problem with some slow network connections where the file remained open for several seconds on the server after TC closed it. Maybe you can increase the number of open files on your server?

handil · Post by *handil » 2011-02-21, 16:14 UTC

I know what a file handle is

, but where can i increase the max number of open file handles. If i remember right, there is an automatism from microsoft (KB818894), included since SP2, that make it for me. So i have no chance to change it.

Why does it not happens with NexusFile, or comp.exe

Ok, i don't know how the programs (NexusFile or comp.exe) compare files, but it must be similar.

For information, tc runs directly on the server with local drives, there is no network access while comparing files

Post by *ghisler(Author) » 2011-02-24, 15:40 UTC

For information, tc runs directly on the server with local drives, there is no network access while comparing files

There should be no problem with file handles then, I have seen this only with remote network shares.

Can you use a tool like "process monitor" from www.sysinternals.com to find out whether there are any read errors in the files which show up as different?