+- XPNEWS.TXT -----------------------------------------+
| |
| ReadMe zum Betrieb des "Enhanced UUZ" |
| mit dem Mail-/News-Client "XPNews" |
| (c) 2003 FreeXP |
| 30.08.2003 |
+------------------------------------------------------+
Diese Datei enthält die Wiedergabe des Textes eines Postings vom
06.06.2003, das alle Detail- und Hintergrundinformationen zum Betrieb
des "Enhanced UUZ" mit früheren Versionen des Mail-/News-Clients
"XPNews" (bis v1.2.2) von Markus Kämmerer enthält. Diese Versionen von
XPNews enthielten einen Bug, der in Korrelation mit einem Bugfix im
"Enhanced UUZ" zu erheblichem Datenverlust beim Empfang von News-Batches
geführt hätte.
Der Text im untenstehenden Posting ist insofern nicht mehr auf einem
aktuellen Stand, als daß kurz nach Erscheinen des "Enhanced UUZ" eine
gefixte XPNews-Version veröffentlicht wurde. Die UUZ-Sonderversion für
XPNews-User wird aus diesem Grund nicht mehr zum Download angeboten.
XPNews-User, die noch eine Version 1.2.2 oder älter einsetzen, müssen
daher *vor* Verwendung des "Enhanced UUZ" unbedingt auf XPNews v1.2.3
(Build 455) vom 06.06.2003 oder neuer updaten - ansonsten ist Daten-
verlust garantiert!
Eine gefixte XPNews-Version ist erhältlich unter:
http://www.happyarts.de/ftp/xpnews/xpnews.zip
Der untenstehende Text enthält mehrfach noch den Begriff "OpenXP/16".
Inzwischen hat eine Umbenennung nach "FreeXP" stattgefunden.
Düsseldorf, den 30. August 2003
----------------------------------------------------------------------
Empfaenger : de.comm.software.crosspoint
Empfaenger : crosspoint.openxp16.pub.allgemein
Absender : my@openxp16.de (Michael Heydekamp)
Software : CrossPoint [OpenXP/16] v3.40 RC3 (XMS) @ 1805032224 R/C816
Betreff : UUZ-Sonderversion fr XPNews-User (was: Announce OpenXP/16: Enhanced UUZ)
Datum : Do 06.06.03, 00:00
----------------------------------------------------------------------
Hi XP'ler,
Michael Heydekamp <my@openxp16.de> wrote on 06.06.03:
> XP-User, die den externen Client "XPNews" von Markus Kämmerer einsetzen,
> müssen wegen eines Bugs in XPNews sowie eines damit unverträglichen UUZ-
> Bugfixes desselben Autors, der in den "Enhanced UUZ" übernommen wurde,
> eine einmalig erscheinende Sonderversion dieses UUZ verwenden -
> ansonsten ist Datenverlust beim Empfang von News-Batches garantiert!
> Bitte dazu die nächste Nachricht lesen, die sich direkt auf diesen
> Announce bezieht.
Damit ist fast alles gesagt - wen die technischen Hintergründe dazu
interessieren, findet diese weiter unten.
Die einmalig erscheinende Sonderversion des "Enhanced UUZ" für XPNews-
User ist hier erhältlich:
WWW: http://www.openxp16.de/download.php#uuz_download
FTP: ftp://ftp.openxp16.de/openxp16/snapshot/uuze_xpn.zip
HTTP: http://www.openxp16.net/ftp/openxp16/snapshot/uuze_xpn.zip
Diese UUZ-Version *muß* zusammen mit XPNews eingesetzt werden, solange
keine Version von XPNews verfügbar ist und eingesetzt wird, in der der
den Datenverlust verursachende Bug (s.u.) behoben wurde.
Technische Hintergründe:
------------------------
In News-Batches stellen externe Clients wie UKAW oder XPNews jedem
Posting einen "rnews"-Header voran, der die Länge des Postings in Bytes
enthält und der für den UUZ das Ende des einen und damit gleichzeitig
den Anfang des nächsten Postings in diesem News-Batch kennzeichnet:
----------8<----------
| #! rnews 922
| Path: [...]
----------8<----------
Dieser Wert ist bei von XPNews erzeugten "rnews"-Headern nicht korrekt
bzw. nicht RFC-konform, denn das Tückische ist, daß RFC1036 und seine
inoffiziellen Nachfolger definiert haben, daß Zeilenenden (EOL) *immer*
als 1 Byte zu zählen sind, auch wenn sie aus mehreren Bytes (so wie bei
CRLF, CRCRLF o.ä.) bestehen sollten:
----------8<----------
News messages are combined into a script, separated by a header of
the form:
#! rnews 1234
where 1234 is the length of the message in bytes. Each such line is
followed by a message containing the given number of bytes. (The
newline at the end of each line of the message is counted as one
byte, for purposes of this count, even if it is stored as <CARRIAGE
RETURN><LINE FEED>.)
----------8<----------
Man kann dieser Bestimmung am sinnvollsten und einfachsten Rechnung
tragen, indem man einfach auch nur aus 1 Byte bestehende Zeilenenden
erzeugt (also reine CRs oder LFs) - dann nämlich stimmt der Wert im
"rnews"-Header automatisch. Nach diesem Prinzip verfahren Clients wie
UKA_PPP oder UKAW.
XPNews hingegen erzeugt aber eben keine aus einzelnen CRs oder LFs
bestehenden EOLs, sondern CRLF-Zeilenenden mit 2 Bytes. Das kann man
tun, sofern man sicherstellt, daß man sie gemäß RFC1036 auch nur als 1
Byte zählt - aber eben das tut XPNews nicht, sondern es zählt ein CRLF
als 2 Bytes und erzeugt so einen zu hohen Wert im "rnews"-Header.
Und genau das führt bei der Konvertierung solcher News-Batches zum
Datenverlust: Der UUZ liest aufgrund der fehlerhaften Längenangabe im
"rnews"-Header über das Ende der Nachricht hinaus, befindet sich dann
irgendwo mitten in der nächsten Nachricht und trifft deshalb dort jetzt
nicht auf den eigentlich erwarteten "rnews"-Header am Beginn dieser
nächsten Nachricht -> es paßt gar nichts mehr.
Aber warum war das mit dem alten UUZ kein Problem?
Gute Frage. :) Die Geschichte entbehrt nicht einer gewissen Ironie:
Bisher enthielt der UUZ quasi genau denselben Bug wie XPNews, so daß
sich diese beiden Bugs gegenseitig neutralisiert haben: Beide Programme
haben CRLFs als 2 Bytes gezählt, alles war "gut".
Anläßlich eines Bugreports eines Users, dessen empfangene News-Batches
mit CRLF-Zeilenenden und RFC-konformer Längenangabe im "rnews"-Header
nicht korrekt konvertiert wurden (es entstand Datenverlust) hat Markus
selbst (!) dann im Mai 2002 die Ursache dafür durch genau den Bugfix im
UUZ von OpenXP/32 beseitigt, den OpenXP/16 jetzt von dort übernommen
hat:
----------8<----------
Revision 1.105 2002/05/24 06:54:52 mk
- fixed handling of size parameter for messages
----------8<----------
Aufgrund dieses Bugfixes werden jetzt zwar News-Batches mit CRLF-
Zeilenenden und korrekter Längenangabe im "rnews"-Header ohne
Datenverluste konvertiert, dafür *entstehen* jetzt aber Datenverluste
bei News-Batches mit CRLF-Zeilenenden und *nicht* korrekter Längenangabe
im "rnews"-Header. Und eben solche erzeugt XPNews.
IOW: XPNews ist bereits seit über einem Jahr zusammen mit OpenXP/32
nicht mehr einsetzbar, und zwar weil Markus (gleichzeitig Autor von
XPNews) einen Bug im UUZ behoben hat und demzufolge der Bug in XPNews
nicht mehr wie bisher neutralisiert wird. Aufgefallen ist das bisher
wohl nur deshalb nicht, weil offenbar kein OpenXP/32-User XPNews
einsetzt.
Genau dieselbe Situation haben wir nach der Übernahme des Bugfixes nun
logischerweise bei OpenXP/16. Deshalb erscheint diese einmalige
Sonderversion des "Enhanced UUZ", in dem der Bugfix von Markus
deaktiviert ist, damit XPNews-User trotzdem von den übrigen Vorteilen
des Enhanced UUZ profitieren können, ohne von Datenverlusten betroffen
zu sein.
Sobald eine korrigierte Version von XPNews verfügbar ist, sollte jedoch
umgehend auf diese upgedatet *und* dann auch auf den "offiziellen"
Enhanced UUZ mit aktiviertem EOL-Fix gewechselt werden. Denn je
nachdem, wie die Korrektur in XPNews aussehen wird, können dann mit
*dieser* UUZ-Sonderversion für XPNews erneut Datenverluste entstehen:
Sollte eine korrigierte XPNews-Version reine LF-Zeilenenden schreiben,
bestünde diese Gefahr nicht. Schreibt sie aber nach wie vor CRLF-
Zeilenenden - nur dann auch mit korrekter Längenangabe im "rnews"-Header
- dann wäre erneuter Datenverlust bei Einsatz dieser UUZ-Sonderversion
für XPNews vorprogrammiert.
Wie die Korrektur von XPNews letztlich aussehen wird (und ob sie
überhaupt erfolgt), entzieht sich meiner Kenntnis. Markus ist seit
mehreren Monaten über diese Problematik informiert, die einzige
Reaktion, die anstelle eines eigentlich zu erwartenden Bugfixes indirekt
zu mir durchgedrungen ist, war, daß laut RFC822 das Schreiben von CRLF-
Zeilenenden RFC-konform sei.
Das ist korrekt, wird aber weder bestritten noch trifft es den Punkt.
RFC822 gilt nur für Mail, hat daher gar nichts mit News-Batches zu tun
und ist zudem nicht mehr aktuell (es wurde ersetzt durch den Nachfolger
RFC2822). Jedenfalls gibt es bei Mails keinen "rnews"-Header mit
Längenangabe, von daher besteht das Problem dort schon deshalb nicht.
Insofern bin ich angesichts dieser völlig am Problem vorbeigehenden
Reaktion nicht ganz sicher, ob es überhaupt verstanden wurde. Sie ist
auch um so überraschender, als daß Markus beim Einbau des EOL-Fixes in
den UUZ von OpenXP/32 im Mai 2002 die entsprechende Stelle aus einem der
für News zutreffenden RFCs im Code als Kommentar sogar selbst zitiert
hat und daher in Kenntnis dieser Problematik schon damals die fatalen
Folgen für XPNews hätte absehen können oder sogar müssen.
Warum überhaupt diese UUZ-Sonderversion für XPNews und die ausführliche
Erläuterung der Hintergründe? Drei Gründe:
1. Zur reinen Information für alle Betroffenen (User und Programmierer
von XPNews), auch damit hinterher keiner sagen kann, er habe nichts
gewußt oder dies und jenes sei nicht klar oder ausführlich genug
dargestellt worden.
2. Im Interesse der XPNews-User, die den Enhanced UUZ einsetzen möchten,
ohne von unerwarteten Datenverlusten betroffen zu sein bzw. auf einen
XPNews-Bugfix warten zu müssen.
3. Als vorbeugende Maßnahme gegen den möglichen absurden Verdacht,
OpenXP/16 habe diese Änderung im UUZ vielleicht leichtfertig oder gar
mit böser Absicht vorgenommen. Dem ist alleine durch den Umstand,
daß Markus den EOL-Bugfix schon vor über einem Jahr in den UUZ von
OpenXP/32 selbst eingebaut und OpenXP/16 ihn jetzt nur übernommen
hat, zwar eigentlich bereits der Boden entzogen, aber wir möchten
gerade solche Diskussionen schon im Vorfeld abfangen, da sich die XP-
Gemeinde in der Vergangenheit bei Einführung neuer Software oft eher
in solche Nebensächlichkeiten verbissen statt mit dem eigentlichen
Thema beschäftigt hat.
Es ist allerdings nicht geplant, permanent zwei UUZ-Versionen up-to-date
zu halten, so daß dies voraussichtlich die erste und gleichzeitig letzte
UUZ-Sonderversion für XPNews sein wird. Von daher wäre es schon schön,
wenn der Bug in XPNews beizeiten gefixt würde, damit es bei zukünftigen
Updates von OpenXP/16 nicht zu Problemen kommt.
Michael