[Tc 11.0-11.1-11.02 RC5] Compare file bug

[retalv]

I think I found a bug in the file content comparison.
After copying or synchronizing large files (24630.0 M, VMware Virtual Machine Win10) with subsequent verification of the copied file, I receive a copy error not due to TC (it also occurs when using Double Commander, so the drive is probably to blame ).
However, when I compare the two files which confirms the error at around 13% of the file, I get a blank screen with a noticeable reading error, in other words it does not display the differences between the two files.
I understand that it takes an alignment of the planets to find this bug but could you fix it?
The situation concerns TC11.0 and following. I attach screenshots of TC and Double Commander.
Greetings.

[img]https://i.ibb.co/3hLDf0J/TCcompare.png[/img]
[img]https://i.ibb.co/26swMy4/DCcompare.png[/img]

[Horst.Epp]

Sorry, but there is no bug to fix.
Having hardware errors which also doesn't allow successful read of files can't be fixed by TC
or any other software.

[ghisler(Author)]

You get a reading error when the compare tool fails to access a specific part of the file which it tries to display (file read error). So what you see isn't a bug in Total Commander, it's a read error.

Moderator message

Moved to English forum

[retalv]

If it were a REAL reading error due to a hardware defect it would ALWAYS not be read, any software that tried to read it, therefore in the comparison it would also cause Double Commander to go into a verification error which instead reads the file and compares it with the entire original file, from top to bottom, reporting and displaying a single byte that does not correspond to the two files.
The disk of the original file is an SSD while the copied file resides on a mechanical HD recently reformatted (without quick formatting) with the operating system and whose surface I subsequently checked with Macrorit Disk Scanner without detecting hardware defects of any kind.

I understand that many bug reports later turn out to be false, but that's not always the case... maybe take a look by building a file as large as the one that concerns me... right?

[ghisler(Author)]

TC maps larger files into memory, so it's indeed possible to get a reading error because a certain position is only read when you go there (probably in 4kByte chunks).

[retalv]

Dearest, my answer is late due, as you well know, to the time it takes to carry out convincing tests which can be useful to those who have a problem similar to the one described and don't know where to put their hands. Personally, I am convinced that from the time ARPANET was born (I was 9 years old) to the current Internet, the spirit has always been the same (even if the use has actually gotten much worse), that is, sharing information and experiences, but let's quickly get to the point...

After your suggestion regarding the memory mapped verification, I tested the RAM (G.SKILL F4-3600C18D-16GTZRX 16GB(8GB*2) + 16GB(8GB*2) 32GB total) with PassMark MemTest86 PRO: in the past I had had some similar problem regarding the RAM memory, but I deluded myself that I had solved it by slightly lowering the frequency of the XMP profile from the conical 3600Mhz.

Having started the standard cycle of 4 tests on the 4 DIMMs of the system, I received a single error in a single cycle (out of the 4 programmed) in DIMM-B1, test 11 (random numbering) which, however, made me suspicious because the difference in the expected value and the one read in hexagesimal differed by exactly two units, exactly what happened regarding the verification error on the copied files.

I restored the XMP profile of the RAM (3600Mhz) and ran MemTest86 again, receiving about fifteen errors between DIMM-B1 and DIMM-A1, third and fourth DIMM banks but nothing on A2 and B2.
Rechecking carefully the compatibility of the RAM in relation to the motherboard (MSI B550-A PRO) I noticed that the specifications stated that the DIMMs were tested on 1 or 2 slots but not on 4 as was the case on my system, so I removed the A2 DIMMs and B2 and I positioned B1 on B2 and A1 on A2 as per the manual leaving A1 and B1 empty, in other words I removed the two DIMMs without problems and replaced them with the two with problems.

Rebooted the system and ran MemTest86 again, the two DIMMs that seemed corrupt now passed the 4 standard test cycles and hundreds of cycles of the single test 11 without any problem at the speed defined by the XMP profile: in other words the illusion that filling four slots and not only two with the same RAM were not problematic, it dissolved immediately.

Now everything works regularly and obviously also the verification of large files in TC (I kept the RC5 version not having variables): I thank you for directing me on the right path, for my part thinking about memory control is (unfortunately) after all the rest.

[Usher]

2retalv
Maybe you should change your power supply and test all 4 RAM modules again.

[retalv]

Thanks for the suggestion but I doubt it can solve it: I have two machines, an MSI B550-A PRO and an ASUS PRIME X470-PRO both with Ryzen CPUs and powered by CORSAIR RM750X power supplies. In both the problem with the third and fourth DIMM G.SKILL F4-3600C18D-16GTZRX is present and can be solved 100% by eliminating those DIMMs: having 32GB of RAM is not worth the expense of one or two new power supplies especially with the current prices. Looking at the glass half full, now I have RAM to replace a possible breakage...

Looking on the WEB in general and in particular on Amazon regarding DIMM returns ... https://www.amazon.it/product-reviews/B07D97JWDR/ref=cm_cr_unknown?filterByStar=one_star&pageNumber=1 you can see that I am not alone regarding the problem.