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 352762 - Using Replace in many pages corrupts data
Using Replace in many pages corrupts data
Status: RESOLVED FIXED
Product: bluefish
Classification: Other
Component: application
1.0.5
Other All
: High critical
: ---
Assigned To: Bluefish Maintainer(s)
Bluefish Maintainer(s)
: 342537 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-08-24 23:43 UTC by Alberto Gonzalez
Modified: 2006-08-27 02:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test documents (13.49 KB, application/x-compressed-tar)
2006-08-26 15:24 UTC, Alberto Gonzalez
Details

Description Alberto Gonzalez 2006-08-24 23:43:29 UTC
Please describe the problem:
Using the "Replace" function from the Edit menu with the option "Starts at all opened files begin till end" can corrupt the data of many of the files opened and spoil a whole website. It happened to me with about 10-12 php+html files opened, where I wanted to find and replace in all of them cellspacing="5" to cellspacing="8". The string appeared about 6 times in each page, and about 30% of them got corrupted in different ways (cellcellspacing="8", cellspacing="8""5", etc...) I repeated this in a test directory to make sure it's reproduceable and it happened again.

Steps to reproduce:
1. Open about 10-12 pages in Bluefish
2. Select "Replace" (Ctrl-H), look for a string that will be found about 6 times per page and replace it for a similar one in "All opened files begin till end"
3. Scan all the pages for the replaced string to find different levels of corruption in some of them (about 30% in my case).


Actual results:
Data gets corrupted and therefor unusable unless manually repaired if the case allows it.

Expected results:
Data would be cleanly replaced without corruption.

Does this happen every time?
Yes, so it seems.

Other information:
I set this as critical becasue it can spoil a whole website, in some cases beyond easy recovery. In my case it wasn't that bad, but it could cause havoc if used in a whole big website.
Comment 1 Daniel Leidert 2006-08-25 00:18:08 UTC
@Alberto: Please tell us, under which distribution you use bluefish.

The bug is unreproducible here (recent Debian Sid). Anybody able to reproduce it?

Comment 2 Michèle Garoche 2006-08-25 01:25:57 UTC
Would it be that the reporter checked the overlap option?

It is unreproducible here also.
Comment 3 Jim Hayward 2006-08-25 03:22:21 UTC
I can't reproduce it here right now either. Can you tell us exactly what options were selected?
Comment 4 Alberto Gonzalez 2006-08-25 10:12:15 UTC
I use Arch Linux with all packages up to date. Bluefish works fine apart from this bug.

I followed the steps again in a different directory with HTML-only files (in case the PHP code would be the problem) but it also happened there.

The options were all default. All boxes were unchecked.

One example. I searched for cellspacing="0" in all files opened and replaced it for cellspacing="1". And I got thing like this:

<table width="100%" bordecellspacing="1"ng="0" cellpadding="0">

I'll try to ask in Arch's forums in case it's an Arch'sspecific bug and let you know.



Comment 5 Alberto Gonzalez 2006-08-26 13:28:21 UTC
Someone else using Arch couldn't reproduce it either. I thought it could be caused by using the latest GTK+/Pango or something, but it seems it just happens to me.

If anyone has any idea where this kind of bug could come from, please let me know so I can try to identify it.

Thanks.
Comment 6 Michèle Garoche 2006-08-26 14:18:32 UTC
Apart from being the latest Gtk/Pango, which I doubt strongly, here's a few ideas:

1 - Which settings do you have in preferences?
This might help reproduce the bug.

2 - Could you attach a minimal file?
Maybe it is something with encoding or line endings.

Also it's worth noting that, as Jim probably, I'm running a patched 1.0.5 version of bluefish (basically patched with almost all the bugs corrected in 1.0.6).
It may make a difference too.
Comment 7 Alberto Gonzalez 2006-08-26 15:24:05 UTC
Created attachment 71654 [details]
Test documents
Comment 8 Alberto Gonzalez 2006-08-26 15:24:31 UTC
I reproduced the bug in a diferent distribution (a Spanish one based on Ubuntu Breezy). It had Bluefish 1.0.4 installed. I left all preferences in their default state. Steps to follow:

1 - Open all the files attached in Bluefish.

2 - Open the replace dialog. Search for 'cellspacing="0"' and replace it for 'cellspacing="1"' in all opened files till end.

Look at the last few appearances of that string in each page (the first ones don't get corrupted, just the last ones and only in some of the documents).

Note that the files attached are just an example. I first found the bug in other files that came from a completely different source, so the bug (if anyone can reproduce it) is not specific to these files.
Comment 9 Jim Hayward 2006-08-26 16:04:02 UTC
Reproduced here now with 1.0.6rc3. I have not checked CVS HEAD yet. 

It is probably going to be a problem with multi-byte characters. The files as downloaded were ISO-8859-1. Resaving/reopening the files as UTF-8 changes the way files are corrupted when the replace is performed.

Comment 10 Jim Hayward 2006-08-26 19:07:08 UTC
OK here sre some test packages to try. See if this fixes the problem for you.

4b668f9b92f78f3cd02a66da9b7cf1a1  bluefish-1.0.6rc3.1.tar.bz2
cbd1107dd860e769ea5d402e2391b50a  bluefish-1.0.6rc3.1.tar.gz

http://www.linuxexperience.net/bluefish/snapshots/bluefish-1.0.6rc3.1.tar.bz2
http://www.linuxexperience.net/bluefish/snapshots/bluefish-1.0.6rc3.1.tar.gz

Comment 11 Alberto Gonzalez 2006-08-26 19:44:02 UTC
I installed the package and I couldn't reproduce the bug in any way. It's gone completely as far as I can say !

Thak you very much for you attention, and great work.

I'll keep using this release until 1.0.6 final is out. If anything comes out 'll post back.

Thanks :)
Comment 12 Jim Hayward 2006-08-27 01:43:20 UTC
 Fix committed to the 1.0.x branch of CVS. CVS HEAD does not have this bug.
Comment 13 Jim Hayward 2006-08-27 02:01:31 UTC
*** Bug 342537 has been marked as a duplicate of this bug. ***