After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 677237 - Ubuntu 12.04, 64bits, Meld 1.5.3, unable to compare most html files.
Ubuntu 12.04, 64bits, Meld 1.5.3, unable to compare most html files.
Status: RESOLVED DUPLICATE of bug 632540
Product: meld
Classification: Other
Component: filediff
1.5.x
Other Linux
: Normal major
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2012-06-01 00:24 UTC by Eveline Bernard
Modified: 2012-06-01 20:21 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Testcase file 1. (313.52 KB, text/html)
2012-06-01 14:25 UTC, Eveline Bernard 		Details
Testcase file 2. (313.52 KB, text/html)
2012-06-01 14:26 UTC, Eveline Bernard 		Details

Description Eveline Bernard 2012-06-01 00:24:59 UTC 
Unable to compare most html files.

The attempt to open the second file mostly results in a message like this: 
"Could not open file
/home/eveline/Desktop/Link to Encore/Documentatie/Enchelp_comment/79.html appears to be a binary file."

I am absolutely sure this is pure html.
Comment 1 André Klapper 2012-06-01 13:53:50 UTC 
Needs a testcase.
Comment 2 Eveline Bernard 2012-06-01 14:25:20 UTC 
Created attachment 215424 [details]
Testcase file 1.

Testcase file 1: 71.html. This file opens fine.
Testcase file 2: 71_comm.html. Mend refuses to open this file compare with.
Comment 3 Eveline Bernard 2012-06-01 14:26:45 UTC 
Created attachment 215425 [details]
Testcase file 2.

See comment at Testcase file 1.
Comment 4 Kai Willadsen 2012-06-01 20:21:06 UTC 
71.html and 71_comm.html are the same file, and Meld won't open either of them.

The problem is that these files are UTF-16 encoded text, which contains NULL bytes. Checking for NULL characters is a common (but flawed) check for binary files, which ends up being wrong whenever we encounter UTF-16 text.

Anyway, this is a duplicate of bug 632540; we need a better way of handling files that look like they're binary. There's a workaround listed in that bug, but it's ugly.

*** This bug has been marked as a duplicate of bug 632540 ***