Fileformate des Maustauschprogramms CAT letzte Änderung 31.8.07 Inhaltsverzeichnis Versionen Version 1 Version 2 Verwendete Datentypen Datentypen die in Version 1 und 2 gleich sind Datentypen die sich bei Datenbank Version  1->2 geändert haben Die einzelnen Files Die Gruppenfiles CATGROUP.DAT CATGROUP.INF GRUPPEN.INF GRUPPEN.POS Die Messagefiles Filenamen der Messagefiles *.PAR *.DAT *.TAB *.WAI Sonstige Cat-Files     info.inf   Little-Endian <> Big-Endian   In-und Outfiles    Versionen Bei Version 4.50 von CAT wurde ein leicht verändertes Datenformat eingeführt. Diese Doku gilt aber für beide Versionen:   Version 1: für Catversionen <4.50 Ab Catversion 4.30 wird itemCc unterstützt     Version 2: für Catversionen >=4.50 Ab Catversion 5.00 wird itemCc und weitere neue Headerzeilen unterstützt CAT <Version 4.18 kann nur Version 1 Datenbanken lesen CAT ab Version 4.18 kann beide Versionen lesen und wandelt sie ggf. in das für dieses CAT-Version typische Version, denn schreiben können alle CAT-Versionen nur ein  Format. Probleme gibt es natürlich wenn CAT 4.18 eine V.2 Datenbank liest, die die Erweiterungen braucht, also z.B über  64K Messages in einer Gruppe hat oder einen Text >64kB hat. In diesem Fall wird versucht die Gruppe  nur-lesend zu öffnen. Bei der Gruppen.Pos werden solche Fehler ignoriert, da das schlimmste was passieren kann ist, das eine falsche Mail als aktuelle angezeigt wird. Versionsnummern sind in 2 Filetypen gespeichert: Gruppen.Pos   : diese gilt nur für dieses File *.par  : diese gilt außerdem für die zugehörigen   *.dat *.tab  und *.wai   Files Verwendete Datentypen   Datentypen die in Version 1 und 2 gleich sind Datentypen per #define oder typedef Datentyp Definition Erklärung   _BOOL #define _BOOL int   CATDATE typedef _ULONG  CATDATE; Datum im Cat-Format   CAT_GROUP_NUMBER typedef UWORD  CAT_GROUP_NUMBER Cat interne Nummer einer Gruppe   CRC16 typedef _UWORD  CRC16; eine 16Bit CRC   data_len typedef _UWORD  data_len; Länge von Datenblöcken max 64kB   data_offset typedef _UWORD  data_offset Beginn im Datenblock   MSGBITS typedef _UWORD  MSGBITS; Bitmap: Definition der Bits  s.u.   _UBYTE #define _UBYTE unsigned char 8 Bit unsigned int   _ULONG #define _ULONG unsigned long 32 Bit unsigned int   _UWORD #define _UWORD   unsigned int  16 Bit unsigned int   _VOID #define _VOID void   _WORD #define _WORD int  16 Bit signed int enum Datentypen Typ Wert Bezeichnung Beschreibung           rwState     Schreib- bzw Lesestatus   0 rwNA unbekannt   1 rwOn Die Gruppe ist eingeschaltet   2 rwPossible Lesen:Die Gruppe kann man durch einfaches Bestellen erhalten.  Schreiben:Ist wohl sinnlos bei Schreibzugriff, wird aber möglicherweise  später mal genutzt, um Schreibzugriffe nur für die  Leute zu erlauben,  die die Gruppe auch bestellt haben.    3 rwAskChef Leserechte gibt's auf Antrag beim Gruppenchef.  Ein Antrag beim Gruppenchef ist notwendig, um den Schreibzugriff zu erhalten.    4 rwAskSysop Die Gruppe ist eine Netzgruppe, die es in der Box nicht gibt, aber für die Box erlaubt ist, und die der Sysop bestellen kann. Man frage ihn also danach.    5 rwImpossible Die Gruppe ist eine Netzgruppe, die der Box nicht erlaubt ist.    6 rwDefault Die Gruppe ist eine Pflichtgruppe und nicht abschaltbar.    7 rwNoPermission Die Gruppe ist eine Netzgruppe, die der Box nicht erlaubt ist.            uState     Benutzerverhaeltnis   0 uNA unbekannt   1 uIsChef Gruppenchef   2 uIsUser Mitglied   3 uNoUser keines von beiden           netState     Vernetzungsstatus   -2 nPrivate Persönliche Pseudogruppe, erst ab CAT 4.54   -1 nOeffentl Öffentliche Pseudogruppe, erst ab CAT 4.54   0 nNA unbekannt   1 nNet vernetzt   2 nLokal lokal   3 nNetLokal lokal nicht vorhandene Netzgruppe    4 nNetForbid eine Netzgruppe, die für diese Box nicht bestellbar ist            orderState     bestellt?   0 oNA     1 oOn ja   2 oOff nein Die einzelnen Bits aus MSGBITS Name Bit Erklärung bGelesen 0x0001 bFiltered 0x0002 bInteressant 0x0004 bTeilloeschung 0x0008 bTotalloeschung 0x0010 bKommentieren 0x0020 bAntworten 0x0040 bUser1 0x0080 bUser2 0x0100 bVererben 0x0200  /* bFiltered = 10; */ bComToOwnMessage 0x0400 Statusbits einer Msg bOldDupe 0x8000 Vorlaeufig bis bei der Maus die Message-Ids diesen Namen auch verdienen ab Cat 5.19 existiert dies nicht mehr bOwnMessage 0x4000 eigene Messages werden gekennzeichnet bOldComToOwnMessage 0x2000 da einige Betaversionen das so hatten, wird in einer Uebergangsphase  beides erkannt und ggf. 13 entfernt und dafuer 10 gesetzt     Datentypen die sich bei DatenbankVersion 1->2 geändert haben   Datentypen per typedef Datentyp Definition in V.1 Definition in V.2 Erklärung   ITEMBITS typedef _UWORD  ITEMBITS;  typedef _ULONG  ITEMBITS Bitmap:Definition der Bits  s.u.   mess_len typedef _UWORD  mess_len; typedef _ULONG  mess_len; Länge des Textes einer Message   MSGNR typedef _UWORD  MSGNR;  typedef _ULONG  MSGNR; Messagenummer in einer Gruppe Spezialnummern  s.u. Die einzelnen Bits aus ITEMBITS    Bit in V.1 Bit in V.2 Beschreibung   Versionen             itemVon 0x0001 0x0001 Absender     itemAn 0x0002 0x0002 Empfänger     itemMId 0x0004 0x0004 Haupt-MessageID     itemRId 0x0008 0x0008 Haupt-Refferenz-ID     itemBox 0x0010 0x0010 Organization     itemName 0x0020 0x0020 Realname des Absenders     itemRefNr 0x0040 0x0040 2. ID, nur in Mausversion     itemDistribution 0x0080 0x0080 2. Ref-ID, nur in Mausversion     itemGate 0x0100 0x0100 Gateway     itemMime 0x0200 0x0200 Mime Information: Charset,..     itemFollowup 0x0400 0x0400 Followup bei News     itemReplyTo 0x0800 0x0800 na was wohl     itemSender 0x1000 0x1000 der Sender     itemAttachment 0x2000 0x2000 Anhänge s. a. die Beschreibung des Anhangstrings 4.3x, 4.4x, ab 5.00 itemCc     0x00004000L   Kopienempfänger   ab5.00   itemBcc     0x00008000L   Empfänger von &acute;blinden&acute;Kopien   ab 5.00   itemEZeitX     0x00010000L   Ergänzung zur Zeitangabe im Par-File. Format: YYYY SS +ZZZZ mit Y=Jahr; S=Sekunde; + = + oder -; Z=Zeitzone   ab 5.00   itemRef     0x00020000L   References-Zeile aus Internet-Header   ab 5.00   itemRetPath     0x00040000L   Return-Path-Zeile aus Internet-Header   ab 5.00   itemPath   0x00080000L Path-Zeile aus Internet-Header ab 5.00 itemMailer   0x00100000L X-Mailer-Zeile aus Internet-Header ab 5.00 itemKeyW     0x00200000L   Keywords-Zeile aus Internet-Header   ab 5.00   itemResent     0x00400000L   Resent-Zeile aus Internet-Header   ab 5.00   itemTrace     0x00800000L   Trace-Zeile aus Internet-Header   ab 5.00   itemReceived     0x01000000L   Received-Zeile aus Internet-Header   ab 5.00   itemGruppe   0x02000000L Gruppe ab 5.45  itemUnknown   0x4000   0x40000000L   Unbekannte Zeilen      itemPrivateBytes   0x8000   0x80000000L   Status,...     Beschreibung des Anhangstrings Der Anhangstring besteht aus einem Header, je einem Block pro Anhang und der Länge der Originalnachricht.Letzteres ist  formal ein Anhang-Block Dies wird erst von Cat ab den Versionen 4.42/5.12 angefügt. Zwischen Header und dem 1. Block  ist ein Doppelpunkt, die einzelnen Blöcke sind durch Semikolons getrennt Leerzeichen sind wichtig. Es ist in erster Linie ein  maschinenlesbares Format, das aber auch halbwegs lesbar sein sollte. Aus Kompatibilitätsgründen, zu alten Cat-Versionen und zu Fremdprogrammen habe ich für die Anhanginformation einen String verwendet. Teil alternative Formate Variable Beschreibung         Header a/m a Anzahl Anhänge, dabei wird der Pseudoanhang der die Textlänge enthält nicht gezählt. a =Anzahl+´0     m Modus wie in AttachTMode. m=Mode+´0´ hieraus, dem Anhangordner und dem Tauschdatum ergibt sich der Ordner in dem sich das Anhangfile befindet. Ab Cat 5.45 gibt es auch ReadOnly-Anhänge. Bei diesen ist m=Mode+´A´. Beim Verschieben von Nachrichten wird so verhindert, daß der Anhang mit der alten Nachricht gelöscht wird Block F:N =O F Benutzter Zeichensatzfilter.     N Filename des Anhangs     O Originalfilename. Ist dieser gleich zu N kann  O incl Gleichheitszeichen entfallen. Kann O erzeugt werden indem bei N ein Nummernsufix entfernt wird, so entfällt O, das Gleichheitszeichen bleibt  aber. Steht dort also nur ´name.txt´ so ist auch O=name.txt. Steht dort ´name_3.txt´ so ist O ebenfalls name.txt   N =O N,O s.o.   F:N = F Benutzter Zeichensatzfilter.Kann auch entfallen     N Ein Filename der Form name_12.ext. Der Originalfilename kann durch Abschneiden der Zahl ermittelt werden, also hier name.ext.   F:N F Benutzter Zeichensatzfilter.Kann auch entfallen     N Der verwendete Filename ist gleich zum Originalfilename Pseudoblo ck #:l l Pseudoanhang: Die Originalfilelänge, dieser muß nach den normalen Anhängen folgen, so daß die ersten a Anhänge richtige Anhänge sind. Dies gewährleistet u.a. auch die Abwärtskompatibilität. Zeichensatzfilter Cat merkt sich beim Abspeichern von Textanhängen mit welchem Zeichensatzfilter dieser bearbeitet wurde, um so auf  Wunsch des Users den Anhang wieder zurück in das Originalformat wandeln zu können. Dies ist aber nur bei Zeichensätzen mit 256 Zeichen oder weniger möglich! Kennung Beschreibung     1-9 Die Ziffer kennzeichnet den ISO8859 Zeichensatz, eine 1 bedeutet also ISO8859-1. Gefiltert wurde durch Cat vom ISO 8859-n in den Atari-Zeichensatz. Es sind nicht alle 9 in Cat realisiert. F Dies ist die HEX-Ziffer F, analog zum vorigen kennzeichnet es also den ISO8859-15 Zeichensatz X Ein Cat unbekannter ISO-8859 Zeichensatz, also nicht 1-9 oder 15 W Gefiltert wurde durch Cat vom Windows1252-ZS in den Atari-Zeichensatz U Gefiltert wurde durch Cat vom UTF8 in den Atari-Zeichensatz. Hierbei ist zu beachten, daß UTF-8 viel mehr Zeichen enthält als der Atari-ZS, folglich ist hier keine Umkehrbarkeit gewährleistet. K:(nName) Gefiltert wurde Keytab vom Zeichensatz Name in den Atari-Zeichensatz. Name ist der sog. ShortName des Filters. n gibt die Länge dieses Namens an, als Ziffer. Dies ist nötig, da es keine Aussage gibt  welche Zeichen der Name enthalten Kann und ein ´\0´sich als Abschluß verbietet. Die Kennung könnte also z.B. so aussehen: K:(6CP1252) Hier hätte Keytab also von der Codepage 1252 gewandelt. M Eine Dokodierung war nicht möglich, der Anhang wurde also mime-Kodiert abgespeichert. R Dies kennzeichnet einen von Cat generierten Anhang der Zusatzinformationen bei multipart/related Anhängen enthält. Dies muß falls vorhanden der 1. Anhang sein # Pseudoanhang. Hier folgt die Original-Textlänge. Dies entspricht also keinem File! Dieser Anhang muß hinter den richtigen Anhängen sein.   Spezialnummern für MSGNR Name Definition in V.1 Definition in V.2 Erklärung   dataSys_empty 0xffff 0xffffffffl keine Message o.ä.   dataSys_notSaved 0xfffe 0xfffffffel nicht gespeicherte Message   Die einzelnen Files   Die Gruppenfiles Diese 4 Files enthalten Infos zu allen (catgroup.*) oder allen in der Datenbank vorhandenen (gruppen.*) Gruppen. Die beiden INF Files enthalten nur redundante Daten, werden von Cat also ignoriert solange die catgroup.inf   in Ordnung ist.  Sie dienen im Normalfall eher dem User als leicht lesbare Alternative.   Catgroup.dat Bereich Typ Name Beschreibung Enthält die maschinenlesbaren Infos zu allen Gruppen Header _ULONG CatMagic "CATG" _UWORD   Version 4 _UWORD VersionMagic 0x0104 Blöcke einer pro Gruppe data_offset name Offsets in data hinein, der erste ist immer 0. Ansonsten heißt  ein offset von 0, dass das Feld nicht vorhanden ist data_offset netname data_offset chef data_offset kurztext data_offset sysop data_offset followup data_offset herkunft data_offset sprache data_offset alias CAT_GROUP_NUMBER readNumber nach dieser Nummer werden die Gruppen angezeigt, sie beginnt mit 1! Gruppen die nicht in der Datenbank sind haben die readNumber   dataSys_notSaved CAT_GROUP_NUMBER   catNumber interne Gruppennummer, sie beginnt mit 1! Die Messages zu der Gruppe  mit catNumber 1 stehen in gruppe00.par, gruppe00.dat, gruppe00.tab und ggf  gruppe00.wai! Gruppen die nicht in der Datenbank  sind haben die catNumber dataSys_notSaved rwState readState Lesestatus aus F-Zeile rwState writeState Schreibstatus aus F-Zeile uState userState Benutzerverhaeltnis aus F-Zeile netState isNet Vernetzungsstatus aus F-Zeile _BOOL hasProg _BOOL withDollar _BOOL selected Für Darstellung in Liste, wird beim Einlesen auf FALSE gesetzt orderState ordered Für An-/Abbestellen von Gruppen _WORD orderDays Madness-Erweiterung: Gruppe soviel Tage zurück bestellen data_offset dataLength Die Länge des folgenden Datenblocks _VOID  * data Datenblock mit name...alias Catgroup.inf   Bereich Name Beschreibung Dies ist eine reine Textdatei. Es ist eine andere Form der Catgroup.dat  . Sie dient eher dazu von Menschen gelesen zu werden, Cat ließt sie  nur wenn es beim Lesen  der catgroup.dat   Probleme gab. Zeile Jede Zeile entspricht einer Gruppe. Die einzelnen Einträge sind  durch TABs getrennt. gName Gruppenname, immer vorhanden nName Netzname oder nichts cLine Gruppenchef  uLine Kurztext sLine Sysop oder nichts rLine Follow-Up  oder nichts rNumber readNumber: Achtung als vorzeichenbehafteter int -> statt   dataSys_notSaved  staht hier also "-2" cNumber catNumber: Achtung als vorzeichenbehafteter int -> statt   dataSys_notSaved   staht hier also "-2" fLine Flags oLine Geordnet? oNumber orderDays  hLine Herkunft  pLine Sprache  aLine Alias  oder nichts Gruppen.inf   Bereich Name Beschreibung Dies ist eine reine Textdatei.Sie dient auch eher dazu von Menschen  gelesen zu werden, Cat ließt sie nur wenn es beim Lesen der catgroup.dat  und catgroup.inf  Probleme gab. Dann wird versucht aus dieser Datei und der ITG oder IGK eine neue catgroup.dat  aufzubauen.  Zeile Jede Zeile entspricht einer Gruppe der Datenbank. Sie sind nach der catNumber  geordnet. Bis Cat 4.23/4.53 wurden fehlende catNumber einfach ausgelassen,  außerdem  fehlen dann die Gruppen mit catNumber größer als  der Anzahl Gruppen. Gab es also Gruppen mit catNumber 1,2,4,5 so wurden hintereinander 1,2,4 geschrieben. Ab 4.24/4.54 wird für fehlende Nummern eine Fehlermeldung  geschrieben, und natürlich alle Gruppen. Wird eine solche gruppen.inf von einem alten CAT gelesen so wird es eine Gruppe mit der Fehlermeldung als Namen eingefügen, das ist unschön aber besser als das Chaos, daß  entsteht wenn ein altes Cat sine alte fehlerhafte gruppen.inf liest. gName Gruppenname, ab Cat 4.24/4.54 kann hier auch die Fehlermeldung "ERR:Gruppe  fehlt!" stehen.  Gruppen.pos Bereich Typ Name Beschreibung In diesem File stehen Informationen zu Lesepositionen u.ä. in den Gruppen die in der Datenbank enthalten sind. Header _ULONG CatMagic "CAT " _UWORD Version 1 oder 2 _UWORD VersionMagic 0x124 Blöcke zuerst der 'save'-Block, dann einer pro Gruppe MSGNR aktuellePos MSGNR neuePos MSGNR letztePos MSGNR unreadPos MSGNR unreadCount    Die Messagefiles Diese Files enthalten die einzelnen Messages. Der Filename hat eine der folgenden Formen:   Gruppe Form Bsp. Persönliche (=Gruppe 0) private.* private.par: Par-File der Gruppe Persönliche Gruppen 1-100 gruppeXY.* mit XY=Gruppennummer-1 gruppe00.par: Par-File der Gruppe 1 Gruppen 101-1000 gruppXYZ.* mit XYZ=Gruppennummer-1 grupp100.par: Par-File der Gruppe 101   *.PAR Bereich Typ Name Beschreibung sozusagen das Inhaltsverzeichnis, da die Blöcke hier eine konstante  länge haben kann man leicht auf eine bestimmte Message zugreifen. Header einmal am Filanfang _ULONG CatMagic 0x43415420L ="CAT " _UWORD Version Datenbank Version  1 oder 2 dies gilt für *.par,*.dat *.tab  und *.wai _UWORD VersionMagic 0x123 Block ein Block pro Message CRC16 crc crc ueber den Rest des Parameterblocks CATDATE Datum Datum im CAT-Format  ITEMBITS   items In der DAT vorhandene Dinge, in der Reihenfolge wie oben angegeben MSGBITS bits data_len   hLength Laenge des MessageHeaders data_len   idLength ID-Laenge im Header mess_len   Length Laenge der Mitteilung _ULONG   Start Offset in der Datendatei MSGNR upMess Verkettung nach oben MSGNR downMess Verkettung nach unten MSGNR rightMess Verkettung nach rechts MSGNR leftMess Verkettung nach links MSGNR KomCount Anzahl Kommentare *.DAT   Startadresse Bereich Typ Name  Beschreibung Hier stehen die Infos variabler Länge zu den Messages, die   *.PAR  dient als Inhaltsverzeichnis. Start  [mess] Blockheader Einer pro Message _UBYTE ID[idLength  ] ID meist die kurze ID, kann aber auch die lange sein ;-) _UBYTE fb[odd] Füllbyte falls idLength  ungerade ->odd=0 oder 1 Start  [mess]+idLength  +odd _WORD   anz Anzahl Einträge Start  [mess]+idLength  +odd+2 _WORD   offset[anz  ] Offset der Einträge (Betreff und dann aus items  ) Start  [mess]+offset  [0] _UBYTE Betreff[] der Betreff der Message Start  [mess]+offset  [i] die einzelnen Eintäge  (0<i<anz   ) aus items  meist C-Strings Start  [mess]+hLength Text _UBYTE Text[] Messagetext, Strings, die mit lf getrennt sind. Demnaechst einmal noch nullterminiert am Ende. Start  [mess]+hLength  + Length Dupe dupeInfoType Aus Redundanzgruenden doppelt gespeicherte Information (wie in der  *.PAR  ) CATDATE Datum Datum im CAT-format ITEMBITS items In der DAT vorhandene Dinge,in der Reihenfolge wie oben angegeben MSGBITS bits data_len hLength Laenge des MessageHeaders data_len idLength ID-Laenge im Header mess_len Length Laenge der Mitteilung _ULONG Start Offset in der Datendatei  -- Bis hier genau wie in pBlock -- _UWORD setTerminator 0xaa00 beendet den Datensatz Start  [mess+1] nächste Message     Zusatzinfo zu den "Einträgen" Bis auf die beiden letzten Einträge (itemUnknown  und itemPrivateBytes) sind alle Eintraege nullterminierte Strings und nur  vorhanden, wenn in "items   " angegeben. Die Reihenfolge gemäß "items" wird eingehalten. Also einmal mit Hausnummern: items = 00000000 00101101 = 2D hex heisst,  dass es ausser der Message-ID und dem Betreff noch einen Absender, eine Gateway-Message-ID, eine Kommentar-ID und eine Namensangabe in dieser Reihenfolge im Header gibt.   Weiter Textinformation In der Sparte "Weiter Textinformation" stehen Informationen, die von der Maus geliefert werden, aber die Cat noch  nicht kennt. Es handelt sich dabei um eine Liste nullterminierter Strings, die mit einem leeren String beendet wird. Der erste Buchstabe der Strings entspricht dem vom MausTausch-Protokoll uebergebenen.   private-Bytes enthält die bisherige Sonderinfo  aus dem Parameterblock bei persönlichen Msgs. Der Eintrag ist immer 6 Bytes lang und folgendermassen aufgebaut: typedef struct pInfoType {  CATDATE  LeseDatum;  _UBYTE Status  ;  _UBYTE   locked;   /* wenn # 0 dann Status nicht vom User aenderbar */ } PACKED pInfoType; Bearbeitungsstatus Buchst. Name Beschreibung Der Bearbeitungsstatus gibt Auskunft, wo eine persönliche Nachricht  angekommen ist und was der Empfänger damit gemacht hat. A angekommen Mittlerweile ist die Nachricht durch das MausNet in der Zielbox angekommen. B beantwortet Sie wurde beantwortet. G gelesen Die Nachricht wurde gelesen, wurde aber nicht beantwortet. K kopiert Der Empfänger hat die Nachricht jemand anderem als Kopie geschickt,  sie wurde also kopiert. M MausNet Die Nachricht ist im MausNet und noch nicht in der Zielbox angekommen. N nicht gelesen Die Nachricht wurde noch nicht gelesen. T Tausch Der Empfänger hat die Nachricht über den Tausch erhalten. W weitergegeben Die Nachricht wurde weitergegeben. Y Gateway Die Nachricht hat über ein Gateway das MausNet verlassen. Z zurückgestellt Der Empfänger hat die Nachricht zurückgestellt, was bedeutet,  daß er sie zwar gelesen hat, aber erst später entscheiden will,  ob er antwortet           *.TAB Typ Name Beschreibung Enthält die CRCs über die IDs zum schnellen Erstellen einer  Hashtabelle. CRC16 crc1 CRC der MausID (neue CRC-Berechnung ab V.2  ) CRC16 crc2 CRC der Message ID (Erst ab V.2  ) Es wird nicht garantiert, daß die  beiden ID's nicht vertauscht sind. Ist nur eine ID gegeben, so wird sie z.B. als crc1 eingetragen, crc2 ist  dann (CRC16  )dataSys_empty Dies wiederholt sich natürlich für jede Message.   Neue CRC- Berechnung ab V.2 Da die CRC natürlich auch  zufällig  (CRC16  )dataSys_empty  sein könnte wird sie in diesem Fall in V.2   zu 0  gesetzt!! Dies gilt nur bei CRCs aus IDs, nicht z.B. für Block-CRCs   *.WAI Bereich Typ Name Beschreibung Enthält Infos zu Messages die Kommentare zu nicht in der Datenbank  vorhandenen Messages sind, sog. Waisen. Header MSGNR Anzahl Anzahl Einträge Block einer pro Eintrag MSGNR msgNr Nr. der verwaisten Message  MSGNR kommentarAnzahl Anzahl der horizontal verknüpften Kommentare CATDATE ignAft Verfallsdatum, danach besteht keine Hoffnung mehr CRC16 crc1 CRC der RefNr (Referenz auf MausID)  CRC16 crc2 CRC der RId (Referenz auf Message ID)  Es wird nicht garantiert, daß  die beiden ID's nicht vertauscht sind.  Ist nur eine ID gegeben, so wird sie z.B. als crc1 eingetragen, crc2  ist dann (CRC16  )dataSys_empty          Sonstige Cat-Files    Info.inf Bereich Typ Name Beschreibung Enthält die Infos zu den Info-Files Header _ULONG CatMagic 0x43415449L ="CATI" _UWORD Version 2 _UWORD VersionMagic 0x100 Block einer pro Infofile CRC16 crc _WORD new _WORD avail _WORD isMaus _WORD ordered _WORD orderIntervall ORDER_ONCE =-1:  Einmalig ORDER_ALWAYS =0: Immer, 1: täglich, 0-6 bei ITI_ORDERED_WDAY _ULONG lastOrdered Datum in Tagen  seit dem 1.1.1900 _WORD selected _UWORD hasCrc _UWORD res Infofile-Flags _UBYTE mausShort[10] Name z.B. ITG _UBYTE mausName[256] Erklärung _UBYTE filename[256] _UBYTE data[1024] Infofile Flags Name Definition Erklärung ITI_IS_IN_ITI 0x0001 Ist der Eintrag  gerade in der ITI gekommen? ITI_TITLE 0x0002 Ist der Eintrag  eine Titelueberschrift? ITI_GROUP_VISIBLE 0x0004 Ueberschrift -> Gruppe sichtbar? ITI_ENTRY_VISIBLE 0x0008 Eintrag ->  Eintrag sichtbar? ITI_GROUP_MASK 0x00f0 Titelgruppe ITI_GROUP_SHIFT 4 ITI_INFOFILE_I 0x0000 ITI_INFOFILE_J 0x0010 ITI_INFOFILE_O 0x0020 ITI_INFOFILE_S 0x0030 ITI_INFOFILE_U 0x0040 ITI_ORDERED_NOW 0x0200 Sofort bestellen? ITI_ORDERED_WDAY 0x0400 Anforderung nach Wochentag? restliche 6 Bits sind reserviert       Little-Endian <> Big-Endian Der Atari hat einen Motorola 680xx Prozessor. Dieser ist ein Big-Endian Prozessor, im Gegensatz zu Intel-Prozessoren.  Dies ist solange unwichtig wie Daten den Prozessor nicht wechseln. Schreibt also ein Atari das Wort $1234 auf Platte, so  steht dann dort $12 $34, dies würde ein PC als $3412 interpretieren. Probleme würden also auftreten, wenn eine von einem PC-CAT geschriebene Datenbank von einem ATARI-CAT gelesen werden soll. Um dies zu verhindern sind in CAT  Funktionen wie switch_parbuff und n2hs eingebaut. Auf Little-Endian Maschinen sollen sie dafür soren, daß die Datenbank in Big-Endian Manier geschrieben wird. Schön und  gut, nur leider ist das ganze nicht konsequent durchgezogen, z.B. werden in den *.DAT nur die dupe-Struktur gewandelt, und das auch nicht in data_CloseOneWriteGroup. Außerdem wird nach dem Lesen und vor dem Schreiben gewandelt,  doch wenn die Daten nach dem Schreiben noch verwendet werden müßte auch nach dem Schreiben wieder gewandelt werden. Außerdm ist es witzlos diese  Wandlung durchzuführen,  wenn nicht auch beachtet wird ob z.B. ein _WORD 16Bit groß ist. Und  ob in Strukturen  Füllbytes eingefügt werden. Dies alles ist aber  derzeit völlig unwichtig, da es kein PC-CAT gibt. Auch ein CAT, das unter MagicPC läuft verhält sich hier natürlich richtig. In-und Outfiles Maus Die In- und Outfiles sind ursprünglich durch die Maussoftware definiert. S. Mausdoku   Internet (SMTP, POP3, NNTP) Durch die Nutzung von Cat als Mail/Newsclient über SMTP/Pop3/IMAP/NNTP war es nötig diese Files zu erweitern. Die  Grundstruktur ist allerdings gleich geblieben. Also vor allem die Blockstruktur. Geändert haben sich einzelne Blöcke. Solange Cat und In2Cat die einzigen Programme sind, die dieses Format benutzen behalte ich mir vor, dese Doku jederzeit  ohne Vorwarnung zu ändern. Wer also dieses Format auch nutzen will teilt mir dies mit. Ab dann gilt die Definition als fest und kann nur im gegenseitigen Einvernehmen geändert werden. 1)Blockgrenzen In einem Maus-In/Outfile ist jede Zeile die mit einem #beginnt eine Blockgrenze. Dies ist bei den IN-Blocks nicht ganz so  einfach. Es gilt weiterhin, daß jeder Block mit einer #-Zeile beginnt Das Ende eines In-Blocks ist allerdings nur an einer  Punktzeile zu erkennen. Eine Punktzeile ist eine Zeile die nur einen Punkt enthält. Nach dieser Punktzeile folgt dann natürlich wieder eine #-Zeile Es kann aber mitten in einem IN-Block eine Zeile mit einem # beginnen. Wie erkennt man jetzt ob es ein Maus- oder IN-Block ist? Alle IN-Nachrichtenblöcke haben hinter der #-Zeile eine Zeile  die mit iCat beginnt. Hierbei ist die Groß/Kleinschreibung zu beachten. IN-Infoblöcke beginnen mit #Y Maus-Infoblöcke mit #I oder #J  Achtung bis Cat 4.38/5.08 und in2cat 1.03 kennzeichnete Cat IN-Blöcke nicht so konsequent Dies habe ich jetzt geändert,  um es IO-Filtern einfacher zu machen diese Blöcke als IN-Blöcke zu erkennen Wer ein eigenes Programm schreibt, welches In/Outfiles analysiert sollte einfach auf Cat ab 4.39/5.09 und in2cat 1.04 bestehen.  2)CMD-Block im Infile Dies muß der 1. Block sein, sonst wird er von In2Cat ignoriert. 3)Nachrichtenblöcke Hier wird i.W. die Nachricht so übernommen wie sie per POP3 ankommt (Outfile), bzw sie wird so abgelegt wie sie an einen SMTP-Server übergeben werden kann (Infile). Als Doku zu diesem Format empfehle ich die RFC 2822 .  Darüber hinaus gibt es aber noch einige wenige Besonderheiten a)Infile Der Nachrichtenblock beginnt genau wie bei Maus-Infiles mit einer #-Zeile mit der temporären ID Dann folgt bei News eine Zeile die nur die Kennung “iCatGroup” beinhaltet und danach die Newsgroup, gefolgt von Header  und Text der Mail wie er an NNTP weitergegeben wird, mit einer Leerzeile zwischen beiden. Eine typische News sähe also z.B. so aus: #CM0023ZDRH iCatGroup: de.comm.software.mailserver From: Dimitri Junker <news@Dimitri-Junker.de> Newsgroups: de.comm.software.mailserver Subject: SMTP-AUTH Date: Sun, 02 Jun 2002 13:45:44 +0200 X-Mailer: CAT 5.09 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hier steht der Text .   Der Block endet mit einer Zeile die einen einzelnen Punkt enthält, wie in o.g. RFC beschrieben. Bei persönlichen Mails kommt noch die Info für den sog. Envelope hinzu. Statt des obigen iCatGroup steht hier iCatPM,  dann folgt all das was bei SMTP vor dem DATA übertragen werden muß. s. RFC2821 Kapitel 4.1.1.2ff. Bisher sind dies  immer 2 Zeilen: mit Absender und Empfänger für die SMTP-Befehle MAIL und RCPT. Der Rest ist so wie bei den News. Eine typische PM sähe also so aus: #CM0013ZDMQ iCatPM MAIL From:<Dimitri.Junker@Onlinehome.de> RCPT To:<Mustermann@irgendwo> From: Dimitri Junker <Dimitri.Junker@Onlinehome.de> To: <Mustermann@irgendwo> Subject: In2Cat Date: Sun, 02 Jun 2002 11:02:24 +0200 X-Mailer: CAT 5.09 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hier der Text .   Grundsätzlich sollte der 1. Teilblock (also bis zur Leerzeile) einfach zeilenweise an den SMTP-Server übergeben werden, dann der DATA-Befehl mit dem Rest als Inhalt. Das Ende ist auch hier wieder die Punkt-Zeile.  Neu ab Cat V5.34 und In2Cat 2.03 Mailing-List Nachrichten sind ja ein Zwischending zwischen Mail und News. Technisch sind es Mails, praktisch werden sie  aber wie News behandelt. Deshalb markiert sie Cat jetzt mit der Eingangszeile iCatPMPseudo Der Rest ist so wie bei normalen PMs. beachtet wird dies beim zurücksenden eigener Mails. Sie werden also  zurückgesendet wenn dies für ÖMs aktiviert ist, nicht wenn nur PMs zurückgesendet werden sollen.   b) Outfile Im Gegensatz zum Maus-Outfile und zum Infile steht in der #-Zeile keine ID! Hier steht nur eine Kennung, die anzeigt ob es  sich um eine Mail oder News handelt, Außerdem erkennt Cat an dieser Zeile, daß es sich nicht um eine Maus Mail handelt,  zusätzlich zur iCat-Zeile. Ja grundsätzlich hat Cat nchts dagegen wenn beide Formate in einem Outfile gemischt würden. Cat erkennt 3 Typen von Mailblöcken #PM@IN n iCatGroup: Dummytext so beginnt eine Mail im POP3-Format #OM@IN n iCatGroup: Gruppenname so beginnt eine News im NNTP-Format alle anderen Nachrichtenblöcke werden als PM/ÖM im Mausformat interpretiert. Bei PM scheint die iCatgroup-Zeile erstmal unsinnig. Doch benutzten die PM-Filter in Cat bis zur Version 4.40 diesen Platz  um eine Gruppe einzutragen. Ab In2Cat 2.06 wird dies nicht mehr geschrieben. Alle anderen Programme die dies weglassen sollten deshalb genau wie In2Cat darauf hinweisen, daß es nur mit Cat >4.41 funktioniert. Bei News steht hier die Newsgroup aus der die News geladen wurde, also z.B.: iCatGroup: de.comm.software.mailserver   Warum ist diese Angabe der Newsgroup überhaupt nötig? Es gibt doch im NNTP-Header eine Zeile die fast genau so aussieht: Newsgroups: de.comm.software.mailserver Ja, aber hinter Newsgroups ( man beachte das s am Ende) können auch mehrere Gruppen stehen (Crossposting) Und dann wüßte Cat nicht in welche dieser Gruppen es die News einsortieren sollte. Sollen News durch einen Filter in eine Pseudogruppe verschoben werden sollte auch nur die iCatGroup-Zeile verändert werden, nicht die Newsgroups-Zeile. Ab In2Cat 2.06 folgt hinter den @IN noch eine laufende Nummer. Diese dient dazu im #LOG  Block auf Fehler bei der Übertragung hinzuweisen. Diese Fehlermeldungen haben das folgende Format: ? RECV #n: Fehlermeldung RECV ist damit das 2. Schlüsselwort, welches Cat in einer solchen Fehlerzeile (beginnt mit ?) verstehen wird, nach Dupe. n ist die oben beschriebene Nachrichtennummer Und die Fehlermeldung ist Klartext. Nach diesen beiden Startzeilen folgt dann die Nachricht so wie sie der POP3 bzw NNTP-Server übertragen hat, also mit Leerzeile zwischen Header und Text und mit einer Punktzeile als Ende. Infofiles Gruppenlisten Vergleichbar zur ITG (Maschinenlesbare Gruppenliste) habe ich 2 neue Listen definiert. YGA und YGN. Beide bestehen aus einer Gruppenliste, so wie sie der LIST Befehl nach RFC977 Kapitel 3.6.1 liefert.Auch hier dient wieder eine Punktzeile  als Markierung des Blockendes. YGA enthält alle Gruppen, während YGN nur die neuen enthält. Dies erspart Cat jedesmal  wenn es eine neue Gruppe gibt eine vollständig neue Liste aufzubauen, was bei 20000 Gruppen oder so schon ein Weilchen  dauern würde. Interessant in dem Zusammenhang ist noch die Anforderung der YGN. Wie bei allen Infofiles kann hier eine 16-Bit Prüfsumme angegeben werden. Die sollte benutzt werden um das Datum/Uhrzeit der letzten Aktualisierung zu  kodieren. Wie genau dies geschieht ist CAT egal.Da mit einem 16Bit-Wort keine sekundengenaue Zeitkodierung möglich ist  wird man wahrscheinlich gröber unterteilen. Dann sollte man es aber so machen, daß man eher eine neue Gruppe doppelt  erhält, als das eine fehlt. Cat hat keine Probleme wenn in der YGN eine Gruppe steht, die es schon kennt, aber wenn eine fehlt, dann fehlt sie. IMAP Mailboxliste (YMN) Dies ist einfach die Antwort des IMAP-Servers auf den Befehl List "" * Wobei die TAGGED-Zeile abgeschnitten ist, da sie keine Info enthält. Die wohl kürzeste YMN sieht also so aus: * LIST (\HasNoChildren) "/" INBOX Weitere Infofiles Sollten irgendwann weitere IN-Infofiles definiert werden, so werden diese auch mit einem Y beginnen. Dies ist wichtig, da  man ggf. unbekannte Blöcke übergehen sollte, dazu muß man natürlich wissen, ob sie mit einer Punktzeile enden oder nicht. Anfang/Ende Blocktyp Bemerkungen #CM123456 Header+Text #... Maus-Infile PM oder ÖM CM123456 ist eine temporäre ID. #CM123456 iCatPM Header+Text . #... IN-Infile: PM CM123456 ist eine temporäre ID. #CM123456 iCatPMPseudo Header+Text . #... IN-Infile: PM ist Pseudo öffentliche Mail CM123456 ist eine temporäre ID. #CM123456 iCatGroup: Gruppenname Envelope, Header+Text . #... IN-Infile: ÖM CM123456 ist eine temporäre ID. #abc@B Header+Text #... Maus-Outfile PM oder ÖM abc@B ist die Maus-ID der Nachricht PM@IN iCatGroup: Dummytext Header+Text . #.... IN-Outfile:PM Normale PM die ggf. von den Cat-internen PM-Filtern verschoben wird. PM@IN iCatPMGroup: Pseudogruppe ,Header+Text . #.... IN-Outfile:PM PM die von einem Filter in die angegebene Pseudogruppe einsortiert wurde. OM@IN iCatGroup: Gruppenname Header+Text . #.... IN-Outfile: ÖM normale ÖM.