[X] mv Kernel Panic
Dirk Haun
dirk@terra:journal> mkdir journal
dirk@terra:journal> mv journal ..
Mit anderen Worten: Ich befinde mich im Verzeichnis "journal" und will
einen darin befindlichen Ordner, der ebenfalls "journal" heißt, eine
Ebene nach oben bewegen. Dort gibt es natürlich eine Namenskollision mit
dem schon vorhandenen Ordner - aber muss das gleich eine Kernel Panic
auslösen?
Hat gerade mal jemand ein anderes Unix zur Hand und ist
experimentierfreudig genug um auszuprobieren, wie es sich in dieser
Situation verhält?
bye, Dirk
Thomas Kaiser
<news:1flw4tm.1a0hmqc19y1f24N%spam...@haun-online.de>:
> Hat gerade mal jemand ein anderes Unix zur Hand und ist experimentierfreudig
> genug um auszuprobieren, wie es sich in dieser Situation verhält?
Debian Linux: mv: cannot overwrite directory '../journal'
Solaris (mv -f): mv: journal is a directory
Eine SGI bei einem Kunden ist gerade nicht erreichbar und mir fehlt grad
Zeit und Lust einen Server in FreeBSD zu booten. Aber was soll der Test
schon? Warum sollten sich seriöse unixoide Betriebsysteme, die seit langem
getestet und stabil sind, auch eine derartige Blösse geben?
Gruss,
Thomas
Dirk Haun
> und mir fehlt grad Zeit und Lust einen Server in FreeBSD zu booten.
Schade, gerade der Vergleich hätte mich interessiert.
> Aber was soll der Test
> schon? Warum sollten sich seriöse unixoide Betriebsysteme, die seit langem
> getestet und stabil sind, auch eine derartige Blösse geben?
Eine Kernel Panic hatte ich auch nicht wirklich erwartet.
Wird mal wieder Zeit für einen Besuch bei
<http://www.apple.com/macosx/feedback/> ...
Uwe Siemon
> Hat gerade mal jemand ein anderes Unix zur Hand und ist
> experimentierfreudig genug um auszuprobieren, wie es sich in dieser
> Situation verhält?
habe hier noch OS X version 10.1.5, welches beim ersten Versuch das
erzeugte Verzeichnis verschwinden lässt und beim zweiten Versuch den
Zugriff verweigert:
[giesing:~/journal] siemon% mkdir journal
[giesing:~/journal] siemon% ls
journal
[giesing:~/journal] siemon% mv journal ..
[giesing:~/journal] siemon% ls
[giesing:~/journal] siemon% mkdir journal
[giesing:~/journal] siemon% ls
journal
[giesing:~/journal] siemon% mv journal ..
mv: rename journal to ../journal: Permission denied
[giesing:~/journal] siemon% ls
journal
[giesing:~/journal] siemon%
Zwar auch komisch, aber wenigstens keine Kernel Panic.
Sonnige Grüße,
Uwe =:-)
Mike Bäuml
> Wie erzeugt man mit dem mv-Kommando im Terminal eine Kernel Panic? So:
>
> dirk@terra:journal> mkdir journal
> dirk@terra:journal> mv journal ..
Bei mir hier unter 10.2.2 lässt sich die Kernel Panic reproduzieren!
Welches OS läuft denn bei Dir?
Da ist wohl ein feedback fällig!
Der Mike
Patrice
>
> Wie erzeugt man mit dem mv-Kommando im Terminal eine Kernel Panic? So:
>
> dirk@terra:journal> mkdir journal
> dirk@terra:journal> mv journal ..
>
> Mit anderen Worten: Ich befinde mich im Verzeichnis "journal" und will
> einen darin befindlichen Ordner, der ebenfalls "journal" heißt, eine
> Ebene nach oben bewegen. Dort gibt es natürlich eine Namenskollision mit
> dem schon vorhandenen Ordner - aber muss das gleich eine Kernel Panic
> auslösen?
>
> Hat gerade mal jemand ein anderes Unix zur Hand und ist
> experimentierfreudig genug um auszuprobieren, wie es sich in dieser
> Situation verhält?
Kann ich grade an meinem Mac (Linux) nicht testen, habe aber ähnliches
schon gemacht. Außer einer Fehlermeldung passierte da aber nix...
Wenn das ein OSX Bug sein soll, dann schreib an
http://www.apple.com/de/macosx/feedback/
Vielleicht gibts dann bald 10.2.3 :-)
mfg,
P.
Dirk Haun
> Bei mir hier unter 10.2.2 lässt sich die Kernel Panic reproduzieren!
> Welches OS läuft denn bei Dir?
Auch 10.2.2 - hatte ich vergessen zu erwähnen.
> Da ist wohl ein feedback fällig!
Schon passiert :-)
Andreas Braukmann
> Dirk Haun schrieb am 19.11.2002 10:27 Uhr in
>
>> genug um auszuprobieren, wie es sich in dieser Situation verhält?
urrgs. Ich bin mir eigentlich ziemlich sicher, dass ich
dergleichen schon unter OS X gemacht habe, und es nicht
zu einem Panic kam.
> mir fehlt grad Zeit und Lust einen Server in FreeBSD zu booten.
Das taete "das Richtige[tm]".
> Warum sollten sich seriöse unixoide Betriebsysteme, die seit langem
> getestet und stabil sind, auch eine derartige Blösse geben?
Naja. Das ist eine voellig simple Operation auf dem Datei-
system, dass ich das fuer OS-X bzw. Darwin eigentlich auch
kaum glauben kann.
[... Powerbook bootet ...]
dizzy:[~] mkdir peng; mkdir peng/peng; cd peng;
dizzy:[~/peng] mv peng ..
[ ... peng! ... Who the f*ck ist Colonel Panic? ...]
Da wirds dann wohl Zeit fuer 'nen Bug-Report.
-Andreas,
... haette starkes Interesse daran, ob das auf einem
10.1.x genauso ist. (Hier nur noch 10.2.2 verfuegbar ...
--
Web-Designer kümmern sich um Schönheit und nicht um Information,
das tun sie schon seit Jahrhunderten so, seit der Erfindung des
Webstuhls. -- Hubert Partl in d.e.b.s und d.c.i.w.a
Andreas Braukmann
> [... Powerbook bootet ...]
> dizzy:[~] mkdir peng; mkdir peng/peng; cd peng;
> dizzy:[~/peng] mv peng ..
> [ ... peng! ... Who the f*ck ist Colonel Panic? ...]
>
> Da wirds dann wohl Zeit fuer 'nen Bug-Report.
Das Problem tritt reproduzierbar auf 10.2.2 Systemen und HFS+
Dateisystemen auf; auf 10.1.x und 10.2.1 konnte ich den Crash
nicht reproduzieren.
hmmm. Ohne genaue Analyse mag *ich* keinen Bug-Report abgeben.
Ich habe also gerade mal versucht, zumindest herauszufinden,
ob der Bug eher im "mv" oder eher im Filesystem-Code zu suchen
ist. Dazu habe ich mir ein "mv" aus dem Darwin CVS (HEAD) geholt:
$FreeBSD: src/bin/mv/mv.c,v 1.39 2002/07/09 17:45:13 johan Exp $
Das ist eine von
$NetBSD: mv.c,v 1.19 1998/07/28 11:41:49 mycroft Exp $
(wie in 10.2.1 und 10.2.2 zu finden) ziemlich verschiedene Code-
Basis.
Das Darwin-Head-Branch-mv triggert den Fehler auf 10.2.2 jeden-
falls ebenso reproduzierbar wie das Standard-mv.
Ich tippe also (vermutet hatte ich es schon vorher) auf ein Pro-
blem im HFS+-Code; bzw. im HFS- und HFS+-Code, denn auf HFS Da-
teisystemen kann man den Crash auch triggern. (UFS benimmt sich
regulaer.)
-Andreas,
... mag nun aber nicht im Filesystem-Code wuehlen, da ich
mit HFS(+) im speziellen und Darwin-Kernelspace-Source im
allgemeinen derzeit noch ueberfordert bin.
Noses
> ist. Dazu habe ich mir ein "mv" aus dem Darwin CVS (HEAD) geholt:
Das haettest Du Dir leichter machen koennen; ein Dreizeiler mit
#include <stdio.h> und einem Aufruf von rename(2) ist alles, was es braucht.
> ... mag nun aber nicht im Filesystem-Code wuehlen, da ich
> mit HFS(+) im speziellen und Darwin-Kernelspace-Source im
> allgemeinen derzeit noch ueberfordert bin.
Feigling. Aber bevor Du in *dem* Schlamm wuehlst, musst Du Dir wirklich die
Gummistiefel anziehen, die bis zum Kinn reichen. Manchmal habe ich den
Verdacht, dass Apple seine Mitarbeiter angewiesen hat, alle verwertbaren
Kommentare aus den Quellen zu entfernen und sie maximal zu verunstalten,
bevor sie zur Veroeffentlichung freigegeben wurden.
Ansonsten ist es eine gute Uebung (ja, ich habe mir - vom rename-sycall
ausgehend - angesehen, was da passiert; ich bin wirklich gespannt, was sie
dagegen tun wollen). Und so ganz kann Deine Beobachtung nicht stimmen, denn
die Bombe ist in 10.2.1 genauso versteckt (Darwin-Quellen < 6.0 wollte ich
mir aber auch nicht holen).
Noses.
Andreas Braukmann
> Andreas Braukmann <irge...@internet-adresse.de> wrote:
>> ist. Dazu habe ich mir ein "mv" aus dem Darwin CVS (HEAD) geholt:
>
> Das haettest Du Dir leichter machen koennen; ein Dreizeiler mit
> #include <stdio.h> und einem Aufruf von rename(2) ist alles, was es braucht.
hmm. Ja. Im Nachhinein stimmt das natuerlich.
Ich fands aber (ganz nebenbei) interessant zu bemerken, dass die
Darwin-Leute zwischendurch mal eben den Basis-Code ganzer Appli-
kationen austauchen. (NetBSD mv raus; FreeBSD-current mv rein.)
> Ansonsten ist es eine gute Uebung (ja, ich habe mir - vom rename-sycall
> ausgehend - angesehen, was da passiert; ich bin wirklich gespannt, was sie
> dagegen tun wollen).
Liegt das Problem denn auf Syscall-Ebene oder doch eher im File-
System-Code?
> Und so ganz kann Deine Beobachtung nicht stimmen, denn
> die Bombe ist in 10.2.1 genauso versteckt
Interessant. Ich hab hier ein fabrikfrisch installiertes 10.2.1
(direkt von der CD, die mit den neuen iBooks ausgeliefert wird)
und mir gelingt es nicht, den Crash zu triggern.
Vielleicht gibt es im 10.2.1 einen Wuergaround fuer das Problem,
der dann bei 10.2.2 versehentlich selbst wieder umgangen wurde?
-And[aber Spekulationen helfen auch nicht weiter]reas
Noses
> Liegt das Problem denn auf Syscall-Ebene oder doch eher im File-
> System-Code?
Im file system.
> Vielleicht gibt es im 10.2.1 einen Wuergaround fuer das Problem,
> der dann bei 10.2.2 versehentlich selbst wieder umgangen wurde?
Nicht wirklich 8-). Wenn ich das ganz richtig verstanden habe, gibt da
irgendwer (tief im HFS) ein Objekt wieder frei, das ihm gar nicht mehr
gehoert, sondern mittlerweile auf dem Weg zur Platte ist. Das sollte den
zustaendigen Programmierer nicht mehr als 10 Minuten kosten.
Noses.
Nils Hott
> Das Darwin-Head-Branch-mv triggert den Fehler auf 10.2.2 jeden-
> falls ebenso reproduzierbar wie das Standard-mv.
>
> Ich tippe also (vermutet hatte ich es schon vorher) auf ein Pro-
> blem im HFS+-Code;
Das wage ich zu bezweifeln, da der Fehler mit gnu mv nicht auftritt. Der
Bug soll übrigens bereits gefixt sein - mit 10.2.3. kriegen wir ihn dann
vielleicht auch.
Gruß, Nils
Andreas Braukmann
> Andreas Braukmann <irge...@internet-adresse.de> wrote:
>
>> Das Darwin-Head-Branch-mv triggert den Fehler auf 10.2.2 jeden-
>> falls ebenso reproduzierbar wie das Standard-mv.
>>
>> Ich tippe also (vermutet hatte ich es schon vorher) auf ein Pro-
>> blem im HFS+-Code;
>
> Das wage ich zu bezweifeln, da der Fehler mit gnu mv nicht auftritt.
Das scheint nichts zu heissen. Hast Du mal <as82tt$1qs4$1...@news.bnc.net>
gelesen? Noses meint, dass der Bug auch schon in 10.2.1 vorhanden sei.
Und da ich den potentiell daraus folgenden Kernel-Crash unter 10.2.1
eben nicht reproduzieren konnte, koennte es durchaus sein, dass gnu mv
den Bug nur nicht triggert. (Ne, die Unterschiede zwischen NetBSD-,
FreeBSD- und gnu-mv werde ich nun nicht analysieren.)
> Der Bug soll übrigens bereits gefixt sein
Hast Du mal 'nen Link oder das cvs-Log dazu greifbar?
> - mit 10.2.3. kriegen wir ihn dann vielleicht auch.
Der Fehler ist sowas von aetzend, dass ich ihn *dringend* als einzelnen
Fix haben moechte.
-Andreas
Noses
>>> Ich tippe also (vermutet hatte ich es schon vorher) auf ein Pro-
>>> blem im HFS+-Code;
>>
>> Das wage ich zu bezweifeln, da der Fehler mit gnu mv nicht auftritt.
>
> Das scheint nichts zu heissen. Hast Du mal <as82tt$1qs4$1...@news.bnc.net>
> gelesen? Noses meint, dass der Bug auch schon in 10.2.1 vorhanden sei.
Zumindest sehe ich da eine sehr gute Gelegenheit, wo ein schon nicht mehr
gelockter Puffer vom file system weiterverwertet wird. Das laesst mehr als
nur eine Moeglichkeit offen: Dass es dieses Problem gar nicht wirklich gibt,
weil ich etwas anderes uebersehen habe, dass es dieses Problem ist, er aber
Glueck hat oder dass da noch eine Zeitbombe schlaeft und fuer dieser Fehler
noch eine ganze Zeit bei uns bleibt.
>> Der Bug soll übrigens bereits gefixt sein
> Hast Du mal 'nen Link oder das cvs-Log dazu greifbar?
Das wuerde mich auch interesseieren, denn es wuerde sich lohnen, meine
Beobachtungen wenigstens mal mit den entsprechenden Leuten durchzukauen,
wenn die Reparatur etwas ganz anderes war.
>> - mit 10.2.3. kriegen wir ihn dann vielleicht auch.
>
> Der Fehler ist sowas von aetzend, dass ich ihn *dringend* als einzelnen
> Fix haben moechte.
Mit einem entsprechenden Supportvertrag wuerde Apple Dir das sofort geben.
8-)
Noses.
Noses
> Andreas Braukmann <irge...@internet-adresse.de> wrote:
>
>> Das Darwin-Head-Branch-mv triggert den Fehler auf 10.2.2 jeden-
>> falls ebenso reproduzierbar wie das Standard-mv.
>>
>> Ich tippe also (vermutet hatte ich es schon vorher) auf ein Pro-
>> blem im HFS+-Code;
>
> Das wage ich zu bezweifeln, da der Fehler mit gnu mv nicht auftritt.
Hm.
Als Grundgeruest habe ich das hier genommen:
#include <stdio.h>
void main () {
system ("/bin/mkdir /tmp/test");
system ("/usr/bin/touch /tmp/test/test");
rename ("/tmp/test/test", "/tmp/test");
printf ("Ja, ich lebe noch.\n");
}
Definitiv nicht toedlich, nicht einmal in 10000 Wiederholungen (was nicht
heisst, dass da nicht auch noch besagte race condition auf uns wartet - oder
aber dass der file system code doch noch woanders sein locking auf die Reihe
bekommt). Jetzt wird es spannend, allerding lege ich jetzt erstmal den
Rechner weg.
Noses.
Andreas Braukmann
> Als Grundgeruest habe ich das hier genommen:
>
> #include <stdio.h>
>
> void main () {
>
> system ("/bin/mkdir /tmp/test");
> system ("/usr/bin/touch /tmp/test/test");
> rename ("/tmp/test/test", "/tmp/test");
BOOM.
> printf ("Ja, ich lebe noch.\n");
> }
> Definitiv nicht toedlich, nicht einmal in 10000 Wiederholungen
In dem Fall mit zwei Verzeichnissen (und genau der wurde ja
auch im Ausgangsposting beschrieben) war es schon beim ersten
Versuch toetlich.
-Andreas
Andreas Braukmann
> Andreas Braukmann <irge...@internet-adresse.de> wrote:
>> Der Fehler ist sowas von aetzend, dass ich ihn *dringend* als einzelnen
>> Fix haben moechte.
>
> Mit einem entsprechenden Supportvertrag wuerde Apple Dir das sofort geben.
> 8-)
Klar. Allerdings beherrsche ich mich lieber eine gewisse
Zeit lang bei der Benutzung von "mv". Schliesslich laufen
bei mir nur (de facto) "data-less" Workstations unter OS-X.
(Da lohnt der Supportvertrag nicht ;-))
Noses
> system ("/bin/mkdir /tmp/test/test");
Argl.
> In dem Fall mit zwei Verzeichnissen (und genau der wurde ja
> auch im Ausgangsposting beschrieben) war es schon beim ersten
> Versuch toetlich.
Das heisst dann "heute Abend noch einmal suchen".
Faszinierendes Problem; ich versuche gerade herauszufinden WAS man alles tun
muss, um ohne panic auf die Schnauze zu fliegen. Und ich verstehe Mach
nicht. 8-)!
Noses.