wundersame code-fehler

[Merkur]

hallo mädels, hallo jungs.
es ist jetzt ca. 22:20 - zeit für eine "gute nacht geschichte".
es ist ein rätsel, dessen lösung ich selbst nicht kenne, und während mein kernel nun endlich kompiliert wird,
will ich die zeit nutzen, um den geneigten leserinnen ein wenig kurzweil zu bieten.
ich hoffe, meine geschichte gefällt euch.

DIE WUNDERSAME WANDLUNG DES QUELLCODES

es begab sich vor nicht all zu langer zeit, das ich mein system auf suse 7.2 aktualisierte.
die konfigurierung verlief ohne zwischenfälle, in diesem zusammenhang insbesondere auch
das abspecken des 2.4.4-4gb kernels.
und ich war zufrieden.
das system lief und lief, bis es mir zu langweilig wurde und ich es mir, auf anregung eines entfernten
bekannten, zur aufgabe machte, eine sap-db installation zu testen.
HEUREKA ! ich bereue zu tiefst ;)
natürlich schafte ich es, meine bootkonfiguration so zu verwirren, daß ich schließlich beschloß,
wieder den standardkernel zu installieren.
erwähnenswert ist in diesem zusammenhang noch, daß ich nun einen anderen ftp-server zur installation
auswählte, nämlich:
ftp.rz.hu-berlin = 141.20.1.43 - ein offizieller mirror
ok, also kernel mit
make menuconfig
konfiguriert (kann ich schon fast im schlafe ;)
make dep bzlilo modules modules_install
und los gehts.
doch - nein, was ist das?
fehlermeldung währen der ausführung von make dep!

make[4] : Entering directory `/usr/src/linux-2.4.4.SuSE/drivers/scsi´
.depend:68: *** unterminated call to funktion `wildcard´: missing `)´ . stop

hallo? - na gut! hab´ zwar keine ahnung von c oder was es ist, aber schulenglisch
herausgekramt und folgendes herausgefunden:

make dep fehlt im file /usr/src/linux-2.4.4.SuSE/drivers/scsi/.depend beim
aufruf der funktion `wildcard´ in zeile 68 eine schließende klammer.

das file aufgemacht, nach zeile 68, verglichen, wie die anderen formulierungen aussehen
und mich schließlich für eine klammer ganz am ende (zeile 100?) entschieden.
make dep
siehe da, dep läuft durch.
so etwas ähnliches passierte dann noch einmal, allerdings beim kompilieren des
kernels, als er die ide_dma.c behandeln wollte.
dort mußte ich aus der bezeichnung "vender" ein "vendor" machen (zeile 699) und
es fehlten 3! x case aufrufe in zeile 700,702,704.
Danach klappte es auch mit dem kernel ;)

tjaaa, da das ganze nun ein rätsel sein soll, hier nun die fragen:
- hat jmnd schon mal etwas ähnliches erlebt?
- wohin sind die richtigen bytes entwischt?
- gibt es den sport ftp-server hacken um linux-user zum staunen zu bringen?

falls ein bis zwei leutz auch etwas langeweile haben sollten, wäre ich sehr
an einer verifizierung interessiert, da ich jetzt kaum noch die zeit finden werde,
2-4 downloads und komilierungen durchzuführen.
(141.20.1.43 gegen 202.58.118.12)

gute nacht
uwe

[geronet]

wenn's ein hacker wär würd er bestimmt nicht die header so verändern dass du sie nicht mehr fehlerfrei kompilieren könntest (ausser es ist ein dummer hacker)

kann ja sein dass es übertragungsfehler beim saugen gab..

[Merkur]

<BLOCKQUOTE><font size="1" face="Arial,Helvetica,Geneva">Zitat:</font><HR>kann ja sein dass es übertragungsfehler beim saugen gab..[/quote]

ok, aber werden dann nicht eher unsinnige zeichen übertragen, als daß einfach ganze zeichenketten fehlen?
hat ftp nicht die abfrage, ob das gesendete mit dem empfangenen übereinstimmt, wie tcp/ip (prüfsumme?)
ich habe eigendlich schon ein paar bytes mit ftp geholt, aber das wäre jetzt das erste mal mit solchen auffälligkeiten.

[geronet]

<BLOCKQUOTE><font size="1" face="Arial,Helvetica,Geneva">Zitat:</font><HR> ok, aber werden dann nicht eher unsinnige zeichen übertragen, als daß einfach ganze zeichenketten fehlen?[/quote]

Du musst bedenken dass die Datei komprimiert war (tar.gz) und so merkt sich der zipper nur an welcher stelle dies und das stand. Wenn nun nur die Information fehlt dass genau dort dies und das stand ist das doch klar.