[TC 11.03] Why is it possible to compare a file with itself (in same path) ?

[retalv]

Hello, I hope to tell something new...
TC 11.03 release, if I compare (obviously by mistake) a file with itself on the same disk (Files > Compare by content..) the comparison window opens and I already think this is wrong, it should inform you that the comparison is on the same path, alias not itself. If I start the comparison and the file is short (.sha), it is executed and obviously does not find any differences, displaying that the files are the same, but by pressing [OK] instead of exiting, the search for differences is still carried out.
If the file is long and the user does not notice the mistake he has made, obviously it is a "via crucis" to NOT obtain an appreciable result (despite the fact that the main error is always the user's).
It would be enough for the function to check again that the source and destination paths are NOT exactly the same.
Thank you.

[Dalai]

I don't see a bug here. We can argue about whether or not TC should compare the file with itself. If you come to the conclusion that TC shouldn't do anything (and the "Compare content" window is not clue enough) you can make a suggestion.

The thing is that there are cases where the detection if a file is the same file is not as easy, e.g. in case of hard links or symlinks - different name, maybe even different path, but the exact same file in both cases.

Regards
Dalai

[petermad]

I think I once read that the behavior is like this, to give the user can the opportunity to edit the path in one or both sides in the top of the Compare contents window.

[ghisler(Author)]

When you open the compare tool with the same file on both sides, TC will NOT start the comparison as it does when opening two different files. This way you can pick a different file on one side via >> button.

[retalv]

I'm probably the one explaining myself badly, I created the "Animazione.gif" file posted at the following link.
Reiterating that the original error is the user's, who performs a meaningless check, but that the error would be resolved with the same control routine that executes the F5 COPY command, the fact remains that the comparison routine performs a check of the file but despite finding it identical, proceeds with the byte_to_byte comparison despite having already verified that the "two" files have the same content.

While I understand that it's not worth fixing hours, if there is a reason not to fix it in the future I'd like to know what it is.

Greetings

https://upload.disroot.org/r/eWodaker#C78pNjgFT6C+7L6rNNJUbvFEhvujvoKLAz7n7CCpR48=

[petermad]

the fact remains that the comparison routine performs a check of the file but despite finding it identical, proceeds with the byte_to_byte comparison despite having already verified that the "two" files have the same content.

I agree that after showing the message "The two files have the same content" - there is no need to proceed comparing the files.

[retalv]

Regarding the problem, I would like to specify that it only concerns Windows 10, it does not appear in Windows 11 23H2.
Greetings.

[gdpr deleted 6]

Regarding the problem, I would like to specify that it only concerns Windows 10, it does not appear in Windows 11 23H2.
Greetings.

It also concerns Win11 23H2. Because i can reproduce the behavior shown in your GIF with Win11 x64 23H2 build 22631.3296, using 64-bit TC 11.03. After comparing of the file with itself concludes with the "The two files have the same content!" message box, the "Compare contents" feature looks like as if it keeps reading/comparing the file very slowly (whatever it really does...) with the percentage being incremented in the status bar of the Compare contents window -- in the same manner as in your GIF.

There is something curious going on. The percentage increases extraordinarily and insanely slowly. I am using an nvme SSD Solidigm P44 Pro with an effective read throughput of about 5.5 GB/s in Windows using NTFS file system (the SSD is having a raw read bandwidth of approx. 7 GB/s). But the crawl of the percentage from 0% to 100% in the status bar after the same file has already be determined to contain the same content as itself takes about 33 seconds for a 200 MB file, which is just weird. Reading 2x200 MB should just take less than a second on this SSD, not 33 seconds; some code path in TC's Compare content feature must go totally bonkers here...

[retalv]

Opps... you're right, who knows what comparison I made...
Having done the test again, it happens only and exclusively if the path is on the same disk, as long as the disk is different (and the rest of the path is identical) and everything goes back to working normally.

Just put a check like on the copy procedure, or find out in the sources what causes the problem.

HI!

[JOUBE]

There is no problem. Everthing works well. It is as ghisler(Author) wrote:

When you open the compare tool with the same file on both sides, TC will NOT start the comparison as it does when opening two different files. This way you can pick a different file on one side via >> button.

But if you force that compare by yourself - as you do it in your gif video - then it is your choice.

[gdpr deleted 6]

2JOUBE
It's not the users choice that

[...] the fact remains that the comparison routine performs a check of the file but despite finding it identical, proceeds with the byte_to_byte comparison despite having already verified that the "two" files have the same content.

And it's also not the users choice that

There is something curious going on. The percentage increases extraordinarily and insanely slowly. I am using an nvme SSD Solidigm P44 Pro with an effective read throughput of about 5.5 GB/s in Windows using NTFS file system (the SSD is having a raw read bandwidth of approx. 7 GB/s). But the crawl of the percentage from 0% to 100% in the status bar after the same file has already be determined to contain the same content as itself takes about 33 seconds for a 200 MB file, which is just weird. Reading 2x200 MB should just take less than a second on this SSD, not 33 seconds; some code path in TC's Compare content feature must go totally bonkers here...

Moderator message

Insult removed by moderator. Please follow forum rules and guidelines. Stay on topic, be nice to each other and don't throw insults.

[JOUBE]

2JOUBE
It's not the users choice that

[...]... proceeds with the byte_to_byte comparison...

That is not right. It doesn't "proceeds"... Rather - as can be seen in the video - the user actively pressed the compare button.

Joube

[white]

Moderator message from: white » 2024-03-26, 17:11 UTC

Post by elgonzo deleted because it was off-topic and contained insults.

2elgonzo
Please follow forum rules and guidelines. Stay on topic, be nice to each other and don't throw insults.

[browny]

A while ago I requested for such or similar capability.
The reason was to be able to modify a file while seeing the original contents.
Otherwise it required to make a copy, then start comparing and editing, and afterwards delete a copy and the backup.

[ghisler(Author)]

Moderator message

Moved to will not be changed