Fatal bug: CompareIt! not binary clean: 0x00's replaced

Post your bug reports here.
Post Reply
dandv
Posts: 23
Joined: Fri Jan 07, 2005 4:02 am
Location: San Jose, CA
Contact:

Fatal bug: CompareIt! not binary clean: 0x00's replaced

Post by dandv »

With either CompareIt Unicode 3.8.1.1652 or CompareIt 8-bit 3.8.1633, with no "Ignore" options set, compare the a.db to b.db from http://home.arcor.de/dandv/bugs/compare ... nclean.zip and merge the "virtual lines" at the top of a.db over the text in b.db.

Open b.db in any hex editor (Necromancer's Disk Navigator would be great) and notice that, binary speaking, b.db was messed up:
- most 0x00 bytes have been replaced with 0xB7
- the rest of the 0x00 bytes have been replaced with 0x0A !

Even worse, if you compare a.db and b.db again, both CompareIt!s will say the files are identical!

Hope that helps,
Dan Dascalescu

--
Check out my funny Californian pics at
http://whatsnew.fotki.com/harwons
(bookmark this address and stay tuned to my latest pics :-)

grigsoft
Site Admin
Posts: 1673
Joined: Tue Sep 23, 2003 7:37 pm
Contact:

Post by grigsoft »

Thank you for your report!
In fact 0 chars are not allowed in text files, unless Unicode or other multibyte encoding is used. But in such cases normally you shoudl not be able to merge files. I will check this out.

Guest

Post by Guest »

grigsoft wrote:Thank you for your report!
In fact 0 chars are not allowed in text files
I have custom-format database files and records are separated by 0x00 bytes, and rows are separated by 0x00, 0x00, 0x0D, 0x0A.

You can find a sample at http://home.arcor.de/dandv/bugs/compareit/sample_db.zip

When you compare the two files, you will see why I would need at least patching, if not merging :)

Post Reply