[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Binary zeroes are written at teh end of buffer

From: Konstantin Malakhanov
Subject: Binary zeroes are written at teh end of buffer
Date: 21 Dec 2001 10:59:40 +0100

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381)
 of 2001-10-22 on buffy
configured using `configure --with-msvc (12.00)'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: DEU
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: nil

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

We have a following situation here: our source code is stored at UNIX
server under Rational ClearCase (source control program). UNIX volumes
are mounted via Samba at Windows NT clients. We use clearcase.el of
address@hidden to perform ClearCase actions at files (check-in,
-out, compare versions etc). Now the problem is that saving a modified
file under ClearCase in Emacs 21 adds a random number of binary zeroes
(^@) at the end of file. They are not shown immediately in the buffer,
but physically are present in the file. If one looks at it with other
editor or revert the buffer, they are there then. It looks like the
saving routine of Emacs writes binary zeros at the end of file. It
happens not every time, but often enough. The number of bzeroes is
varying, but they are always at the end of file. It happens in Emacs
whether it is compiled with cygwin or Microsoft VC.

This is very annoying as we cannot merge such files because of binary
garbage.  And it simply prevents us of using Emacs 21 at all.

We have no such problem in the environment but with Emacs 20.7.
It couldn't be Samba itself, as it doesn't happen with other editors.

I understand that this is probably not so easy to resolve problem.
I am willingly ready to help to debug it - building Emacs with some
patches is OK (cygwin or Microsoft VC)

Recent input:
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> C-x 1 <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <prior> <prior> <prior> <prior> 
<prior> <prior> <prior> <prior> <prior> <prior> C-x 
k <return> <menu-bar> <help-menu> <report-emacs-bu

Recent messages:

nnimap: Checking mailboxes...done
Checking new news...done
call-interactively: Quit
Type C-h for help, h for commands, q to quit.
Loading c:/emacs-21.1/lisp/emacs-lisp/pp.elc...done
Loading c:/emacs-21.1/bin/fns-21.1.1.el (source)...done
Type M-x switch-to-buffer-other-window RET to restore the other window.  C-M-v 
to scroll the help.
sw-half-scroll-up: End of buffer [4 times]
Loading c:/emacs-21.1/lisp/mail/emacsbug.elc...done

Konstantin Malakhanov 
ISOWARE GmbH, Feithstr. 142, 58097 Hagen, Germany
email: address@hidden  Tel: 02331/8019-71 FAX: 02331/8019-99

reply via email to

[Prev in Thread] Current Thread [Next in Thread]