DSBMC/DSBMD

Hallo @marcel,

vielen Dank für Deine Rückmeldung! Die Verwirrung und Spannung scheint jetzt zum Glück dem Ende zuzugehen und zufällig ist (zum Glück) nichts: Das Fehlverhalten wird leider von einer ganz konkreten Daten-CD hervorgerufen (uraltes Spiel von Computerzeitschrift). Ich kann jetzt leider nicht mehr nachvollziehen, inwieweit diese CD in der Vergangenheit von früheren Testversionen von dsbmd erkannt und gemountet wurde oder nicht. Jedenfalls funktioniert jetzt es auch nicht mit dsbmc ohne dsbmc-cli -a mit caja. Sämtliche anderen getesteten CD's funktionieren indes einwandfrei und lassen sich mit caja auch wieder auswerfen.

Was auch eine Rolle zu spielen scheint: In dem Verzeichnis /media gab es eine Datei ".hal-mtab", die m.E. bei einer anderen CD manchmal zu einem Fehlverhalten führte:

Wenn die CD geunmountet wurde, verschwand das Symbol in caja. Wenn die CD aber physisch rausgeworfen wurde (Klicken auf "eject" in caja), verschwand das Symbol allerdings nicht. Das Löschen der Datei ".hal-mtab" in /media schien da erfreulicherweise Abhilfe zu leisten.

Es sei jetzt mal dahingestellt, warum eine zufällig ausgewählte alte CD (nicht zerkratzt!) derartige Probleme verursachen kann. Jedenfalls wurde sie unter HAL erkannt (ich weiß jetzt aber nicht mehr genau, ob auch im Laufwerk 1) und hat auch mal im Test mit dsbmd funktioniert.

Es scheint letztendlich bei mir jetzt doch alles in Ordnung zu sein in Bezug auf dsbmd.

Noch eine Frage: Ich glaube hier im Thread gelesen zu haben, dass dsbmd auch MTP-Devices mounten kann? Ich habe mein Handy angeschlossen, aber es passierte leider nichts. Fehlt da noch irgendein Fuse-Port den man vorher installieren muss?

Kleine Beobachtung an Rande: Auch wenn ich hier von caja spreche, teste ich aus KDE heraus, habe caja lediglich zu Testzwecken von dsbmd installiert. Beim Auswerfen einer CD poppen im KDE-Panel nacheinander zwei Textmeldungen auf, in denen ein Symbol zu fehlen scheint. Hat das etwas mit dbus zu tun?
 
Was auch eine Rolle zu spielen scheint: In dem Verzeichnis /media gab es eine Datei ".hal-mtab", die m.E. bei einer anderen CD manchmal zu einem Fehlverhalten führte:

Wenn die CD geunmountet wurde, verschwand das Symbol in caja. Wenn die CD aber physisch rausgeworfen wurde (Klicken auf "eject" in caja), verschwand das Symbol allerdings nicht. Das Löschen der Datei ".hal-mtab" in /media schien da erfreulicherweise Abhilfe zu leisten.
Ich könnte mir denken, dass caja davon ausgeht, dass hald läuft, wenn diese Datei vorhanden ist, was dann zu dem Fehlverhalten führt.

Es scheint letztendlich bei mir jetzt doch alles in Ordnung zu sein in Bezug auf dsbmd.
Sehr gut.

Noch eine Frage: Ich glaube hier im Thread gelesen zu haben, dass dsbmd auch MTP-Devices mounten kann? Ich habe mein Handy angeschlossen, aber es passierte leider nichts. Fehlt da noch irgendein Fuse-Port den man vorher installieren muss?
MTP-Geräte werden mithilfe von sysutils/fusefs-simple-mtpfs gemountet. Der Port wird standardmäßig vom dsbmd-Port installiert, wenn man die Option nicht abgewählt hat. Ob das Handy überhaupt als MTP-Gerät erkannt wird, siehst Du, wenn ein entsprechendes Symbol in dsbmc erscheint, oder in der Ausgabe von dsbmc-cli -l | grep mtpfs

Beim Auswerfen einer CD poppen im KDE-Panel nacheinander zwei Textmeldungen auf, in denen ein Symbol zu fehlen scheint. Hat das etwas mit dbus zu tun?
Da bin ich leider überfragt.
 
Hallo @marcel,

ich wollte es jetzt doch nochmal wissen: Da ich wieder im HAL-Betrieb bin, habe ich die "problematische" CD nochmal ausprobiert. Ich muss Dir leider mitteilen, dass sie mit HAL problemlos gemountet wird. Ich weiß jetzt auch nicht, was man dazu noch sagen soll. Ich weiß nicht, inwieweit es bei CD's vielleicht Qualitätsunterschiede geben kann, auf die Dein Tool möglicherweise empfindlich reagiert. Vielleicht finde ich irgendwann nochmal die Zeit, den älteren Code zu testen und dann wieder zu berichten. Vorläufig bleibe ich aber esrtmal bei KDE/HAL.
 
Könntest Du mal bitte die besagte CD einlegen, und folgendes ausführen?
Code:
sh -c 'i=16; while [ $i -lt 19 ]; do (dd if=/dev/cd0 bs=2048 skip=$i count=1 | dd bs=1 count=6) 2>/dev/null; i=`expr $i + 1`; echo; done'
/dev/cd0 ist natürlich entsprechend anzupassen. Mich interessiert die Ausgabe.
 
Also Du hast jetzt leider nicht weiter spezifiziert, ob das unter HAL, DSBMD oder ohne alles gehen soll. Ich habe es aber einfach mal so gemacht (unter HAL und der device notifier von KDE hat die CD erkannt) und die Ausgabe ist folgende:

Code:
$ sh -c 'i=16; while [ $i -lt 19 ]; do (dd if=/dev/cd0 bs=2048 skip=$i count=1 | dd bs=1 count=6) 2>/dev/null; i=`expr $i + 1`; echo; done'
CD001
CD001
ÿCD001
$
 
Hallo @cabriofahrer

hast Du die Möglichkeit, es mal mit anderer Hardware zu testen? Ich hatte unter dsbmd/dsbmc mit nur einer externen Festplatte das merkwürdige Phänomen, dass beim Klicken auf "Einhängen" ein Mount failed angezeigt wird, beim erneuten Klicken auf "Einhängen" sie aber anstandslos gemountet wird. Das ist reproduzierbar und es betrifft nur diese eine Platte. Ich vermute, sie braucht zu lange für einen Spin Up.

Ist nur so eine Idee. Vielleicht reicht schon ein anderes Laufwerk, damit es bei Dir wieder funktioniert (was nicht heißen soll, dass dein jetziges Laufwerk kaputt ist). Aber manchmal harmonieren gewisse Sachen aufgrund irgendwelcher Kleinigkeiten nicht gut miteinander.
 
@cabriofahrer , ich habe noch eine Idee. Möglicherweise scheitert DSBMD daran, den Typ der CD korrekt zu erkennen, was dazu führt, dass eine Identifikation des Dateisystems erst gar nicht stattfindet. Um das herauszufinden, würde ich Dich bitten, die besagte CD einzulegen und die folgenden Befehle abzusetzen, und anschließend die Ausgabe hier zu posten.
Code:
# fetch http://freeshell.de/~mk/download/testcd.c
# cc -o testcd testcd.c -lgeom
# ./testcd /dev/cd0
 
Hi @holgerw ,

laut @cabriofahrer scheint es nur an einer speziellen CD zu hängen, die von HAL aber erkannt und gemountet wird. Der Fehler muss also bei DSBMD liegen.

Zu Deinem bedingten Problem: Tritt es denn immer noch auf? Wenn ja, welches Dateisystem ist auf der Platte? Welche Version von DSBMD nutzt Du?
 
Hallo @marcel,

Die Ausgabe ergibt bei dieser CD gar nichts (möglicherweise das erwartete Ergebnis?). Nach Ausführen des letzten Befehls (./testcd /dev/cd0) scheint sich die Geschwindigkeit des Laufwerks nochmal zu erhöhen, aber der Cursor bleibt in der nächsten Zeile einfach hängen, bis das Laufwerk schließlich zum Stillstand kommt.

Code:
# service hald stop
Stopping hald.
Waiting for PIDS: 1029.
# fetch http://freeshell.de/~mk/download/testcd.c
testcd.c                                      100% of 5754  B   25 MBps 00m00s
# cc -o testcd testcd.c -lgeom
# ./testcd /dev/cd0

Um sich nochmal sicher zu sein:

Ctrl+C (Danach ist das Entfernen der CD möglich)
Einführen einer anderen CD
Erneut

Code:
# cc -o testcd testcd.c -lgeom
# ./testcd /dev/cd0
90: !has_media()
n == -1
#

Und siehe da, wir haben eine Ausgabe. CD 1 wird also nicht erkannt.
 
Sehr interessant. Was passiert, wenn Du die CD einlegst und anschließend den Befehl
Code:
camcontrol cmd /dev/cd0 -c 0
absetzt?
 
Es passiert gar nichts:

Code:
# service hald stop
Stopping hald.
Waiting for PIDS: 1342.
# camcontrol cmd /dev/cd0 -c 0
#

Allerdings konnte ich die CD danach wieder entfernen. Nach Einführen der zweiten funktionierenden CD und einem erneuten "camcontrol cmd /dev/cd0 -c 0" konnte ich diese allerdings erst nach mehreren Minuten wieder entfernen.
 
Es passiert gar nichts:
Das heißt in diesem Fall, dass der Befehl erfolgreich war.

Nach Einführen der zweiten funktionierenden CD und einem erneuten "camcontrol cmd /dev/cd0 -c 0" konnte ich diese allerdings erst nach mehreren Minuten wieder entfernen.
Das ist seltsam, und zeigt, dass bei Deiner Hardware etwas nicht stimmt. Dennoch kann ich mit den neuen Informationen arbeiten. Ich werde den Test für das Vorhandensein eines Mediums dann wohl über einen SCSI-Befehl umsetzen, was ja offensichtlich besser funktioniert. Danke für Deine Zeit. Ich gebe Dir Bescheid, sobald ich etwas Testbares fertig habe.
 
Das ist seltsam, und zeigt, dass bei Deiner Hardware etwas nicht stimmt.

Da bin ich mir nicht so sicher. Es handelt sich um eines der wenigen Slot-In Laufwerke von damals und das Auswurfverhalten war schon immer etwas restrikiver gegenüber den herkömmlichen Schubladenmodellen. Ein Auswerfen war meist immer erst möglich, wenn die CD wirklich still war. Ein Drücken des Knopfes hat im Gegensatz zu den Schubladenmodellen nicht immer sofort zum Spindown des Motors geführt. Wahrscheinlich ist das so bezweckt.

Und ich danke DIR für Deine Zeit!
 
@cabriofahrer : habe testcd jetzt angepasst. Versuche es mal hiermit:

Code:
# fetch http://freeshell.de/~mk/download/testcd.c
# cc -o testcd testcd.c -lgeom
# ./testcd /dev/cd0
 
Code:
# service hald stop
Stopping hald.
# fetch http://freeshell.de/~mk/download/testcd.c
testcd.c                                      100% of 6030  B   26 MBps 00m00s
# cc -o testcd testcd.c -lgeom
/tmp/testcd-bfaf75.o: In function `has_media':
testcd.c:(.text+0x986): undefined reference to `cam_open_device'
testcd.c:(.text+0x9d1): undefined reference to `cam_getccb'
testcd.c:(.text+0xa03): undefined reference to `scsi_test_unit_ready'
testcd.c:(.text+0xa20): undefined reference to `cam_send_ccb'
testcd.c:(.text+0xa8b): undefined reference to `cam_close_device'
testcd.c:(.text+0xa94): undefined reference to `cam_freeccb'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
# ./testcd /dev/cd0
su: ./testcd: not found
#
 
Entschuldige, die Angabe von -lcam fehlte:
Code:
# cc -o testcd testcd.c -lgeom -lcam
# ./testcd /dev/cd0
 
Zwar keine Fehlermeldung mehr, aber wieder wie oben. Es kommt keine Ausgabe:

Code:
# cc -o testcd testcd.c -lgeom -lcam
# ./testcd /dev/cd0
 
Noch ein Versuch:

Code:
# fetch http://freeshell.de/~mk/download/testcd.c
# cc -o testcd testcd.c -lgeom -lcam
# ./testcd /dev/cd0
 
So, jetzt (was immer das auch bedeuten mag):

Code:
# fetch http://freeshell.de/~mk/download/testcd.c
testcd.c                                      100% of 5685  B   24 MBps 00m00s
# cc -o testcd testcd.c -lgeom -lcam
# ./testcd /dev/cd0
96: Check for media
101: OK
 
(was immer das auch bedeuten mag):
Das heißt, dass zumindest schon mal der Test auf das Vorhandensein eines Mediums geglückt ist. Wir tasten uns ran. Ich habe den Code jetzt noch um einige Debug-Meldungen erweiter, sodass man sehen kann, wo es hakt:

Code:
# fetch http://freeshell.de/~mk/download/testcd.c
# cc -o testcd testcd.c -lgeom -lcam
# ./testcd /dev/cd0
 
Code:
^C
# fetch http://freeshell.de/~mk/download/testcd.c
testcd.c                                      100% of 5994  B   26 MBps 00m00s
# cc -o testcd testcd.c -lgeom -lcam
# ./testcd /dev/cd0
96: Check for media
101: OK
107: Getting sector size
110: OK
111: Reading TOC header
116: OK
119: Reading TOC entry
124: OK
136: seeking
141: OK
146: Reading
151: OK
169: Seeking
174: OK
175: Reading
180: OK
 
Das sieht schon mal gut aus. Kommt das Programm zum Ende oder hängt es nach der Ausgabe
Code:
180: OK
?
 
Zurück
Oben