Bug 109284 - encoding corruption of files?
Summary: encoding corruption of files?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xemacs
Version: rawhide
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-11-06 15:37 UTC by Rik Faith
Modified: 2008-05-01 23:32 UTC (History)
2 users (show)

Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-01 23:32:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Rik Faith 2003-11-06 15:37:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

Description of problem:
Depending on what appear to be unrelated settings, a VM mailbox will
either be corrupted or not.

Version-Release number of selected component (if applicable):
xemacs-21.4.14-3

How reproducible:
Always

Steps to Reproduce:
1. Place the file from http://www.alephnull.com/broken into /tmp. 
This is a stripped-down email message with a few high-bits set.  Make
sure to copy this file in an 8-bit clean manner.
2. cp /tmp/broken /tmp/broken.orig
3. diff -u /tmp/broken.orig /tmp/broken        <-- no diff
4. xemacs -q -eval "(setq default-major-mode 'text-mode)"
5. M-x vm-visit-folder <RET> /tmp/broken
6. d u q
   [to delete, undelete, and quit VM -- you want the modified folder
to be written]
7. diff -u /tmp/broken.orig /tmp/broken
   [note diffs.  the header diffs are ok.  the diff in the "in fact it
has not" is not ok]

Actual Results:  Text of email message modified.

Expected Results:  No modification of email message.

Additional info:

1. cp /tmp/broken.orig /tmp/broken
2. diff -u /tmp/broken.orig /tmp/broken        <-- no diff
3. xemacs -no-site-file -q -eval "(setq default-major-mode 'text-mode)"
    [don't load site files, either]
4. M-x vm-visit-folder <RET> /tmp/broken
5. d u q
   [to delete, undelete, and quit VM -- you want the modified folder
to be written]
6. diff -u /tmp/broken.orig /tmp/broken
   [note only diffs in headers -- NO CORRUPTION NOW]

If you leave off the setq, there will also be only header diffs.  I
have created this example to be easy to run.  However, I have
reproduced this by deleting my .vm and .emacs and creating a new
.emacs with just the setq inside it.  Then you don't have to fiddle
with the command line options.

So, the significant things are:
1) (setq default-major-mode 'text-mode) appears required for broken
behavior
2) -no-site-files must be absent for broken behavior

If you keep editing the folder, the corruption in question appears to
double with each visit, so you eventually have a 100's of megabytes of
corruption in your mbox file.  Argh.

As far as I can tell, this bug goes back to xemacs-21.4.14-2 (at
least), and possibly appeared between Fedora test1 and test3 (I
skipped test2).

Comment 1 Jens Petersen 2003-11-07 09:10:57 UTC
Reproduced.  I note that as you told me, disabling the
utf-8 setup in site-start.el or running in a non-utf8 locale
seems to workaround the problem.

Doesn't seem to be anything new about this though: I can
reproduce it with 21.4.1{2,3} too.

It seems the (setq default-major-mode 'text-mode) is affecting
the coding-system of the folder buffer used by vm. :-[
Though afaict it is only raw-text-unix (without) vs
raw-text (with it).

Anyway I consider this an upstream issue.

Comment 2 Rik Faith 2003-11-07 09:34:00 UTC
> Anyway I consider this an upstream issue.

1) I'd like to submit this to the upstream people.  Is that ok?

2) Does the utf-8 setup in site-start.el ship from the upstream?  If
not, then I suggest that if Red Hat is including non-standard (or,
minimally, unexpected) code in site-start.el, then this is a Red Hat
problem and not just an upstream problem.  (While the bug in the utf-8
support that causes the buffer to grow without bound is clearly an
upstream bug, I'd expect many people to complain if xemacs was
silently converting arbitrary buffers to utf-8 -- especially if the
conversion is sometimes done incorrectly! [i.e., perhaps the horrible
part of this bug has nothing to do with VM?])

Comment 3 Jens Petersen 2003-11-07 12:22:16 UTC
1) That's fine. :)

2) No, the utf-8 setup code is mine.  Without it you basically
get no working utf-8 support in xemacs, so some such code is really
necessary now that all our locale default to utf-8.  This is
the first problem I've heard about it though.

Comment 4 Jens Petersen 2003-11-12 02:24:53 UTC
Actually I realise this is not a VM bug, since I can
reproduce it easily in the following way without VM:

1) run "xemacs -q"
2) M-: (setq default-major-mode 'text-mode)
3) C-u C-x C-f broken RET raw-text RET SPC Backspace C-x C-s C-x k RET
[note that the buffer is marked as being in utf-8 in the modeline]
[the same thing happens with raw-text-unix]
4) C-u C-x C-f broken RET raw-text RET

Observe that the utf-8 text has changed.  It seems the raw-text encoded
buffer is being saved with utf-8 encoding afaict which is quite
strange.  Without step 2 it doesn't happen, as noted earlier.

Comment 5 Jens Petersen 2007-09-02 23:39:31 UTC
Not sure if this is related but I have also experienced corruption of
the fedora owners.list file while editting it with xemacs (both 21.4 and 21.5).

Comment 6 Bug Zapper 2008-04-03 15:31:04 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 7 John Poelstra 2008-05-01 04:56:32 UTC
Should this bug remain open?

Comment 8 Jens Petersen 2008-05-01 23:32:19 UTC
I can't reproduce comment 4 any more with pre-F9.
Most likely this is fixed in F8 already?

Please re-open if this is still a problem.


Note You need to log in before you can comment on or make changes to this bug.