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).
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.
> 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?])
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.
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.
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).
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.
Should this bug remain open?
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.