Mein persoenliches nicht... Und ich kann nicht mehr genau nachvollziehen,
ob das schon eine neuere Version als popper-1.832beta.tar war.
Es begab sich, dass ein Rechner, der als MX und NX und Modemeinwahlrechner
eines Zweigs einer
Individual.net-Mitgliedsdomain diente, an seinem
Aufstellungsort auch ein paar lokale Mailbenutzer hatte, die per
POP3 (ueber popper realisiert) auf ihre Boxen zugriffen.
Es begab sich, dass er von NetBSD-0.9+patches auf NetBSD-1.0 gebracht
wurde.
Es begab sich, dass mir in der beginnenden Woche mitgeteilt wurde,
Mails (von POP3-Usern) ließen sich nicht mehr loeschen, sondern würden
sich sogar verdoppeln oder verdreifachen.
Enter I.S., Perseus[1] vom Dienst.
Aktion eins: zwei Testmails auf lokale Mailbox geschickt.
Aktion zwei: per telnet auf 110 zugegriffen. Einloggen unmoeglich, passwort
hatte ein Leerzeichen. !*&^@%%!*@protokoll. Passwort geaendert.
Aktion drei: per telnet auf 110 zugegriffen.
LIST: ja, alle beide da.
RETR: funktioniert.
QUIT.
Aktion vier: per Mail nachgesehen. 4 Mails da - offenbar A B A B.
Aktion fuenf: per telnet localhost 110 nachgesehen: Ja, A B A B.
Aktion sechs: per Mail nachgesehen. A B A B A B A B. Alle geloescht.
Frisch 2 E-mails reingeschoben.
AKtion sieben: per telnet localhost 110 nachgesehen: A B.
DELE 2. QUIT.
Per Mail nachgesehen: A B A B A.
Hm....
cd .../popper; vi *.[hc]
Les... les... les...
Gar nicht so dumm, das Teil. Statusaenderungen nach Kopie von mbox.
Zurueckschreiben durch flock(); if (neue mails) auch an Kopie haengen,
ftruncate(fd, 0), Kopie in das original 'reinkopieren, funlock().
Bei eigenen Loeschungen passierte das ganze zwischen temporaerer Datei
und temporaerer temporaerer Datei vorher noch einmal. Alles im Dienste
des niemals-eine-Nachricht-verlierens. Und nichts kann passieren, wenn
man sich den Code anguckt.
Nur, dass bei mir sich der Kram verdoppelt. Hm... man ftruncate().
Fehler: keine moeglich, ausser ENOSPACE, aber ich verkuerze ja.
Hm... Schreibschutz kann auch nicht sein, war vorher mit O_RDWR
geoeffnet.
Genau aus dem Grund hatten die Autoren auch (void)ftruncate(...)
geschrieben. Hm...
Was solls, Fehlercode melden, vielleicht passiert ja doch einer.
Wie meldet man in dem !)&@!@-Code Fehler zurueck? Les les... a ja,
so geht das. In beiden Aufrufen von ftruncate() Fehlerbehandlung
eingebaut.
telnet localhost 110, login, RETR, QUIT. ENOSPC. wtf?
man page genauer gelesen. #include <...> steht da oben drin. Steht
das in *.c? O nein: nein. Hinzugefuegt, kompiliert.
telent ... 110 usw: funktioniert.
Wer (ausser mlelstv, der weiss Bescheid) rät die Lösung?
off_t hat in 4.4BSD und NetBSD>=1 "neuerdings" 64 bit, statt 32
wie in 4.3BSD und NetBSD<1. Mit dem Prototypen aus <....h> haette
der Compiler alles richtig gemacht. Ohne hat er die Funktion fuer eine
int ftruncate(int, int) gehalten. Der Kernel hat sich fuer den 2.
Parameter aber 64 bit vom Stack geholt, und anschliessend versucht,
die Datei auf (von null verschiedener muell) * 2^32 zu verlaengern.
Soviel Swapspace hatten wir auf dieser Kiste aber nicht.
Software von Studenten aus Berkeley verflucht, patch eingeschickt.
-is
[1] man Medusa.
