Subj : Re: OpenXP 5.0 =?ISO-8859-1?Q?f=FCr?= Windows =?ISO-8859-1?Q?verf=FCgba To : Gunter From : Zong Date : Thu May 12 2022 18:07:00 From: Zong Gunter schrieb: > - Wenn eine OLDBUF-Datei größer als 2147483647 Bytes ist, ggf. mit > einem geeigneten Text-Editor an einer Mail-Grenze in zwei Dateien > aufsplitten (durchaus knifflig für Ungeübte !!!) Nachbearbeitung von umbeannten MPuffern wäre bei dem Kenntnisstand der meisten hier sowieso das letzte Mittel. Ich gehe mal nur auf die Dateibearbeitung an sich ein, nicht auf den gesamten Ablauf wie Umbenennung, Sicherungskopien, Löschung von *.ix1 und *.db1. Bei solchen Teilungsaktionen mit Editoren entstehen die meisten Auffälligkeiten durch Zeilenendegeschichten oft mit der Folge korrekturbedürftiger Angaben der Nachrichtenlänge. Ein OpenXP ZPR -r korrigiert dann die LEN:-Angaben, aber ich würde immer bevorzugen, dem ZPR keine oder so wenig Arbeit wie möglich zu überlassen. Bei MPuffer-Dateien wird sowieso jeder ZPR was zum Meckern finden. Zum ZPR siehe auch die vorige Antwort. Ich empfehle einen neueren gVim zum Trennen. Der lässt die Zeilenendezeichen und "trailing spaces" das sind Leerzeichen am Zeilenende aber vor den Zeilenendezeichen, also eigentlich alles, in Ruhe. Er nimmt auch keine automatischen UTF-8-Konvertierungen beim Abspeichern vor und kommt mit den genannten Dateigrößen klar. Man orientiert sich im Editor dann am Besten am ersten EMP:-Header. Nach ZConnect muss EMP: nicht die erste Headerzeile sein. Der UUZ (also das Tool welches die ZConnect-Konvertierung vom UUCP-Batch bzw. den Eingangspuffern vornimmt, die unter *.nws im Spool- Verzeichnis nach dem Netcall liegen) schreibt IMHO immer den EMP: als erste Kopfzeile. Ist EMP: nicht die erste, also sind noch andere Kopf- bzw, Headerzeilen davor, dann sollte man vor denen trennen. Schlimmstenfalls ruiniert man sich eine Nachricht und die Längenangabe für die vorherige. Texteditoren bieten oft die Wahl der Zeilenendezeichen an, also CRLF (Windows, Dos), LF (Mac) oder CR (*nix) und fügen die dann meist einheitlich ein. Solche Änderungen der Zeilenendezeichen führen meist zu falschen LEN:-Angaben, also der Nachrichtenlänge nach den Kopfzeilen. (Binärdateien sind durch Texteditoren nochmal besonders gefährdet. Deren Versand ist nach dem Ende der ZConnect zwar nicht mehr von Bedeutung, aber vielleicht liegt noch Binäres in Puffern.) BTW1, ein zeigt die Kopfzeilen, etwas ausführlicher an. zeigt den Nachrichtentext binär in der Nachrichtenübersicht an und man erkennt die Zeilentrennzeichen CRLF = Carriage Return und Linefeed an den sedezimalen Zahlenwerten 0D und 0A dieser Steuerungszeichen. Selbst heute tauchen hier im Body oder dem Textteil der Nachricht auch statt CRLF vereinzelte LF als Zeilenendezeichen auf. Vorgeschrieben bei Text ist ja CRLF in ZConnect, dem Datenformat der MPuffern. Auch der OpenXP-UUZ lässt diese LF durch. Werden vielleicht von XPnews stammen. Der setzt in der Regel CRLF in die *.nws-Dateien, kümmert sich wohl aber nicht um isolierte LF. Ist hier auch nicht weiter bedeutsam, sollte nur ein Hinweis auf die kleinen, möglichen Hindernisse beim Abspeicherns mit einem Text-Editor sein. BTW2, ich verpasse zusammenkopierten Pufferdateien vor dem erneuten Einlesen gerne noch einen Durchlauf durch den 32-Bit ZC-Sort. Dann sind sie nach dem Erstellungsdatum sortiert und erscheinen auch so in der Nachrichtenübersicht. Just my 2 cents :) -- Zong --- * Origin: rbb.fidonet.fi - the fidonet nntp junction (2:221/10) .