Compare by content - feature request (Offset flags)

[Csimbi]

I would like to request a new feature.
I am not sure how many people use the "Compare by content" tool to compare binaries, I personally use it a lot.
Now when You compare files, everything is fine until the files that have a fixed structure, however as soon as You encounter a format where the items may shift a few bytes forth/back, the "Compare by content" tool is pretty useless.
What I had in mind is to be able to drag-and-drop (or just set via right-click menu) little flags to both sides of the panels to any place within the binary stream. Then, when the flags are set, TC aligns the starting positions to the flags on both sides (shifting the content of one of the panels - left or right does not matter), and compares the content starting from those flags on both sides.
There is a workaround to do this, (to use a hex-editor to remove the beginning of the file until the offsets match), however is is quite painful to do.
I understand this is a feature that cannot happen overnight, how ever I hope to see it in a future release.
Thank You.

[ado]

Csimbi,
I don't want to disappoint you, but I am afftaid, that Christian will never implement such feature.
Compare by contents is cool feature and I am using it a lot. But hex mode just fo find out why textmode didn't find any differences - usually becuase of EOL char Win/Unix. ...or when files are binary with the same size, if they are too different. Definitely not to search for the same fragments in 2 files. I even affraid if special hex editors impplement such feature...
Comparing of binary files is quite complex thing and I am affraid there will be always something more important

ado

[Csimbi]

Csimbi,
I don't want to disappoint you, but I am afftaid, that Christian will never implement such feature.
Compare by contents is cool feature and I am using it a lot. But hex mode just fo find out why textmode didn't find any differences - usually becuase of EOL char Win/Unix. ...or when files are binary with the same size, if they are too different. Definitely not to search for the same fragments in 2 files. I even affraid if special hex editors impplement such feature...
Comparing of binary files is quite complex thing and I am affraid there will be always something more important

ado

Dear ado,
I am not using it to find out differences that textmode did not find. I am really comparing binary files - which unfortunately change over time. Let me explain.
There is a database file. It has an index in the beginning, and the content later on. Now when a new item is added to this database, the rest of the data is shifted by 4 bytes (an int) towards the back. Then, the content is added to the back. Now if You try to compare the two copies of the databases, every single byte will be different (except the index up until the change), so there is no way to know what else has been changed (in addition to the adding the content to the back). Now if I could say to TC that: compare the to files from these offsets, then I would not be affected by the shifted bytes, and I could see all changes clearly.
I hope this clarifies.
True, there is no hex-editor or any kind of SW that does this - this is why I think TC should have it first. I believe it would be a great addition to the arsenal (at least for those who hex-compare a lot).
Thanks.

[vserd]

2 Csimbi
Compare Databases its a complex task, and if compare by content shows difference its not mean what files really different.

[Csimbi]

2 Csimbi
Compare Databases its a complex task, and if compare by content shows difference its not mean what files really different.

I am not sure what You mean. Could You clarify?

Replace the word "database" with something else. I can use it to compare any files, not only actual databases.
The problem described above is valid for any file that is change is a way where at least one byte is inserted somehere in the middle. Don't stick to the word database here.
That's why it would be nice to have these flags (or reference points if You like to call it something else).
Thanks.

[vserd]

If file different in one byte its file not equal.

If your task "found identical text|binaries" or "compare text|bnaries some lenght from some offset" you shuld use the special tools.

[q]
if compare by content shows difference its not mean what files really different.
I am not sure what You mean. Could You clarify?
[/q]
Database not record oriented in store. 2 database files has different records/fields ordering. But information in this files equal. Compare by content return difference, but human not found difference in information.

"Compare by content" compares byte by byte the files and this mean what this tool unsuitable for database compare. ((

[aguirRe]

I think Csimbi is right, it would be a good feature. I occasionally have the same problem. Beyond Compare has precisely this feature at least for textual comparisons. You can "lock" two lines, one in each window to help the comparison tool.

As some kind of clumsy workaround, you can hexdump the two binary files to text files, cut out inserted/deleted sections and then compare the text files instead. If the binaries are large or have many inserted sections, this is less useful ...

[Csimbi]

I think Csimbi is right, it would be a good feature. I occasionally have the same problem. Beyond Compare has precisely this feature at least for textual comparisons. You can "lock" two lines, one in each window to help the comparison tool.

As some kind of clumsy workaround, you can hexdump the two binary files to text files, cut out inserted/deleted sections and then compare the text files instead. If the binaries are large or have many inserted sections, this is less useful ...

It seems vserd did not understand what I mean.
I'm glad You understood aguirRe, I was worried there for a moment that I am writing nonsense. Yes, that's exactly what I mean. Beyond compare is no good because I cannot convert the binary files to text - it's including a lot of control characters.

[aguirRe]

Yes, you can. I meant using a utility to hexdump (i.e. generate printable text, e.g. 0A for LineFeed) to a textfile, then there won't be any invalid control chars in that file.

[Csimbi]

That sounds even more cumbersome than to cut out the beginning of the binary file and use TC to compare (I mean: additionally, I would even have to convert the cut file into text).

[ghisler(Author)]

I have already added this feature for text files (called "manual resync"). I will consider to add it for binary files too, although I'm currently not resyncing in binary mode at all now.

[Csimbi]

It would be great, thank You!