DSBMC/DSBMD

Wow, vielen Dank, klappt jetzt einwandfrei!
Super!
llerdings bekomme ich nach dieser Prozedur dennoch

Code:
# pkg info | grep dsbmd
dsbmd-1.2 Media mounting daemon
#
angezeigt?
Das liegt daran, dass die neue Version nicht über die Ports-Infrastruktur installiert worden ist. Die Dateien sind aktuell, aber in der pkg-Datenbank ist noch dsbmd-1.2 registriert.

Und könntest Du Deine Ausführungen von #373 bitte noch etwas genauer erläutern? Was sind die Subclasses 0x5 und 0x6 und warum ist eine davon obsolet?
Die Subclass 0x5 kennzeichnet Geräte, die das SFF-8070i-Protokol benutzen, wobei es sich bei den Geräten wohl häufig um Floppy-Laufwerke handeln soll.
Die Subclass 0x6 ist die am häufigsten benutze heutzutage. Das sind Gerät, die den SCSI-Befehlssatz benutzen.

Und vielleicht hast Du noch eine Erklärung für folgendes Problem, was aber nichts mit dsbmd zu tun hat:

Zum Entfernen der Kamera mache ich zuerst ein ordnungsmeäßes Unmounten. In diesem Fall konnte das jetzt über Thunar geschehen. Dann befolge ich die Meldungen des Displays der Kamera, dass man die Verbindung zum PC beenden soll. Doch manchmal bekomme ich beim Ziehen des Kables einen Totalabsturz, das System macht einfach einen kalten Neustart und es meldet, dass die Festplatte nicht ordnungsgemäß geunmountet wurde und beginnt entsprechend ein fsck.
Das sollte auf keinen Fall passieren. Hast Du mal versucht, das Gerät vor dem Abziehen mal "auszuwerfen"? Etwa per DSBMC oder dsbmc-cli -e?

Das scheint sicherlich ein Problem speziell von FreeBSD zu sein, oder?
Damit solltest Du Dich vielleicht mal an die FreeBSD-Mailingliste wenden.

Ich werde mich indes darum kümmern, dass die 1.3 bald in die Ports kommt.
 
Das sollte auf keinen Fall passieren. Hast Du mal versucht, das Gerät vor dem Abziehen mal "auszuwerfen"? Etwa per DSBMC oder dsbmc-cli -e?

Natürlich, immer, habe ich ja beschrieben. Ohne DSBMC eben manuell mit "#umount /mnt". Das beschriebene Verhalten scheint eher unberechenbar zu sein und tritt in der Regel eben nicht auf, wenn zuerst von PC-Seite geunmountet wird. Ich werde das weiterhin beobachten und mich dann ggf. tatsächlich an die Mailingliste wenden.

Ich werde mich indes darum kümmern, dass die 1.3 bald in die Ports kommt.

Toll! Es dürfte jetzt wirklich ausgereift sein, ich möchte mich nochmal herzlich dafür bedanken, dass Du die ganze Zeit so auf mich eingegangen bist und das Tool entsprechend verbessert hast!

Ich bin jetzt gerade dabei, mich mit XFCE4 anzufreunden, da Thunar wunderbar mit dsbmc-cli -a zusammenarbeitet und MATE mich z.Zt ziemlich enttäuscht, da der hp-systray nicht angezeigt wird und offensichtlich kein Mensch eine Antwort darauf weiß.
Zudem arbeitet XFCE4 wunderbar mit LightDM zusammen, man hat ohne weiteres Zutun auch einen Button zum Herunterfahren, was mir ebenfalls sehr wichtig ist.
Leider hat Thunar keine Funktion zum Suchen von Dateien...

Es wäre natürlich schön, wenn in absehbarer Zukunft KDE/Dolphin und wie ebenfalls hier erwähnt, k3b die Sprache von dsbmd/dsbmc lernen würden. Dazu müsste man mal auf die betroffenen Entwickler zugehen.
 
Es wäre natürlich schön, wenn in absehbarer Zukunft KDE/Dolphin und wie ebenfalls hier erwähnt, k3b die Sprache von dsbmd/dsbmc lernen würden. Dazu müsste man mal auf die betroffenen Entwickler zugehen.

OffTopic: Ich glaube, weitere Details zu dieser Frage kann Dir hier z.B. @tcberner beantworten, vielleicht mal in einem neuen Thread thematisieren.

Noch ein paar Gedanken zum Dateimanager dolphin: Ich habe, obgleich ich dsbmd/dsbmc benutze, sowohl k3b als auch dolphin im Einsatz. Wenn ich ab und an dann mal k3b nutze, setze ich zuvor als root ein
Code:
service hald onestart
ab, dann klappt es auch mit k3b.

Selbst unter meiner Kombination openbox und tint2 nehme ich dolphin. Ich mag keine Dateimanager, die Sachen nicht können, mit denen mich sogar schon konqueror vor zig Jahren verwöhnt hat. Ein drag&drop in verschiedene Richtungen, eine Auswahl "hierher verschieben", "hierher kopieren", "hiermit verknüpfen". Wenn solche Sachen unter Dateimanagern wie nautilus, thunar, pcmanfm u.ä. schon nicht gehen, dann mag ich die einfach nicht nutzen (ist natürlich Geschmacksache). Von Einbinden verschiedener Helferlein ins Rechtsklickmenü fange ich besser erst gar nicht an, das kann meines Wissens nach nur dolphin. Ob dolphin nun per Mausklick Devices ein- oder entbinden kann, ist mir da nicht so wichtig, selbst unter dem ollen Win7 werden externe Devices nicht über den Windowsexplorer entbunden, sondern über ein extra Devicemanagement.

Aber jeder hat da wohl andere Priorisierungen.
 
OffTopic: Ich glaube, weitere Details zu dieser Frage kann Dir hier z.B. @tcberner beantworten, vielleicht mal in einem neuen Thread thematisieren.

Ist das der Entwickler von k3b?

Und im Übrigen @holgerw, kann ich Dir zum Thema Dolphin nur Recht geben: Er scheint wirklich der beste Dataimanager zu sein. Aber Deine Ausführungen bezeugen, dass man unter KDE derzeit mit dsbmd keinen in sich geschlossenen DE hat. Hingegen mit anderen DE's schon. Ich habe z.B. gerade Nautilus unter XFCE4 aufgerufen und der arbeitet auch mit dsbmd zusammen. Wer also auf Gnome3 steht, kann hier ebenfalls wunderbar dsbmd nutzen.

Hier war mal ein Thread, in dem jemand fragte, wie man ein NTFS-Laufwerk mit Gnome3 automounten kann. Also mit dsbmd geht es jetzt.
 
Hallo @cabriofahrer

@tcberner ist einer der sehr aktiven FreeBSD-KDE Leute, denen wir es zu verdanken haben werden, wenn plasma5 demnächst in den offiziellen Repos erscheinen wird. Der kennt die k-Software so gut, dass er meiner Vermutung nach einschätzen kann, ob dsbmd sinnvoll mit dolphn oder k3b kombiniert werden kann.

Nachtrag:
Da fällt mir gerade ein, ich habe vor zwei Tagen erst wieder plasma5 samt k3b mit poudriere gebaut, ich schaue mal nach, ob das Repo auch ohne hal zu bauen ist und wie sich dann z.B. k3b und dolphin verhalten.

Was das veraltete kde4 angeht, wird man wohl um hal nicht herum kommen.
 
Natürlich, immer, habe ich ja beschrieben. Ohne DSBMC eben manuell mit "#umount /mnt". Das beschriebene Verhalten scheint eher unberechenbar zu sein und tritt in der Regel eben nicht auf, wenn zuerst von PC-Seite geunmountet wird.
Ich meinte nicht das Aushängen, sondern Auswerfen im Sinne von eject. In den deutschen Übersetzungen von Software wird auswerfen und aushängen synonym benutzt. Wenn ich etwa meinen Kindle zum Laden an den Rechner anschließe, kann ich ihn nicht benutzen, solange ich ihn nicht ausgeworfen (ejected) habe.
Toll! Es dürfte jetzt wirklich ausgereift sein, ich möchte mich nochmal herzlich dafür bedanken, dass Du die ganze Zeit so auf mich eingegangen bist und das Tool entsprechend verbessert hast!
Ich danke Dir für deine Geduld! Die Schwierigkeiten, die Du hattest, haben einfach bestehende Probleme aufgezeigt, deren Beseitigung DSBMD wieder ein ganzes Stück verbessert hat. Das gilt natürlich auch für alle anderen Fehlerberichte und Verbesserungsvorschläge jener, die sich hier mit eingebracht haben. Ohne die Interaktion mit Euch wäre die Software nicht mal halb so gut.

Was das Zusammenwirken von DSBMD mit den diversen Dateimanagern/DEs betrifft, muss gesagt werden, dass diese ja lediglich darauf beruht, dass diese die Mount-table, bzw. /media auf Veränderungen hin überprüfen. Dadurch kann es sowohl der DE oder dem Dateimanager als auch DSBMD egal sein, wer etwas ein- oder aushängt. Möchte man jedoch per Mausklick von einem Dateimanger aus eine Datenträger einhängen, so müsste dieser sich direkt mit DSBMD verbinden, und dessen Sprache sprechen. Wenn man ohnehin Automount per dsbmc-cli -a benutzt, spielt das keine Rolle. Im Fall von Dolphin würde es ja schon reichen, wenn dieser die Mount-table und/oder /media im Auge behielte, und eine Funktion böte, mit der per Kontextmenü (so wie in Thunar, Caja, etc.) ein normales umount ausgeführt werden kann.
 
Hallo,

ich habe mal in der make.conf HAL auf UNSETTING options gesetzt, und den Bau neu angestoßen, aber das ist wohl nicht hinreichend, hal ist und bleibt weiterhin als Paket im Repo bestehen und es wird auch kaum was neu gebaut..

Heute Nachmittag werde ich mal ein neues Minirepo bauen lassen, in der Portliste ist dann nur x11/kde5 und sysutils/k3b sowie Marcels dsbmd und dsbmc drin. Bei den Options zum Metaport kde5 habe ich in Erinnerung, dass man bei irgendeinem k-Port da anstelle von hal einen bsddisk Modus wählen kann.

Mit diesem Minirepo werde ich dann ein Testsystem aufsetzen, und mal ausprobieren, wie einzelne K-Anwendungen mit bsdmd/bsdmc zusammen arbeiten.

Aber bitte gebt mir etwas Zeit, es kann sein, dass ich erst dieses Wochenende Resultate posten kann.
 
Ich meinte nicht das Aushängen, sondern Auswerfen im Sinne von eject. In den deutschen Übersetzungen von Software wird auswerfen und aushängen synonym benutzt. Wenn ich etwa meinen Kindle zum Laden an den Rechner anschließe, kann ich ihn nicht benutzen, solange ich ihn nicht ausgeworfen (ejected) habe.

Wenn ich also in Thunar auf das Symbol rechts von dem gemounteten Gerät drücke, was mache ich dann? Eject oder unmount? Ich dachte, es gibt da nur einen Unterschied bei optischen Medien, nämlich dergestalt, dass dann wirklich die Schublade des Laufwerks geöffnet wird. Aber bei Sticks oder Festplatten kann es doch keinen Unterschied geben, oder?

Und @holgerw, finde ich super, was Du da ausprobieren willst. Ich bin schon ganz gespannt auf das Ergebnis. Und je nachdem, was dabei herauskommt, könntet Ihr danach Kontakt mit dem hier erwähnten KDE-Entwickler aufnehmen.
 
Wenn ich also in Thunar auf das Symbol rechts von dem gemounteten Gerät drücke, was mache ich dann? Eject oder unmount?
Thunar kann nur aushängen. Es sei denn, es ist eine CD/DVD.
Aber bei Sticks oder Festplatten kann es doch keinen Unterschied geben, oder?
Es ist nicht sehr intuitiv, aber auch ein USB-Stick kann ausgeworfen werden (siehe auch camcontrol(8)). Dadurch wird der Logik im Stick gesagt, dass man nicht mehr auf ihn zugreift. Wenn es ordentlich funktioniert, verschwindet auch das daX-Gerät aus /dev. Bei manchen Geräten wird dann auch die Stromzufuhr zum Gerät abgestellt. Du kannst per DSBMC (Kontextmenü), per dsbmc-cli -e und per camcontrol eject auswerfen. Vielleicht hilft das ja, die Crashes zu verhindern.
 
Wenn es ordentlich funktioniert, verschwindet auch das daX-Gerät aus /dev. Bei manchen Geräten wird dann auch die Stromzufuhr zum Gerät abgestellt.

Interessant. Vielleicht erklären sich damit die gelegentlichen Abstürze im Zusammenhang mit der Kamera. Ich nehme mal an, dass der Absturz verursacht werden kann, wenn das daX-Gerät vielleicht noch nicht aus /dev verschwunden ist, wenn ich das Kabel ziehe. Ich war natürlich nie auf diese Idee gekommen, aber ich werde mal in /dev reinschauen, nach welchem Schritt genau (auch auf dem Display) das Gerät verschwindet.
 
Interessant. Vielleicht erklären sich damit die gelegentlichen Abstürze im Zusammenhang mit der Kamera. Ich nehme mal an, dass der Absturz verursacht werden kann, wenn das daX-Gerät vielleicht noch nicht aus /dev verschwunden ist, wenn ich das Kabel ziehe. Ich war natürlich nie auf diese Idee gekommen, aber ich werde mal in /dev reinschauen, nach welchem Schritt genau (auch auf dem Display) das Gerät verschwindet.
Es ist nur eine Idee. Das System sollte, wenn ein Medium ausgehängt worden ist (man kennt das ja noch von gemounteten USB-Sticks, die man einfach mal abzieht), nicht abstürzen. Aber vielleicht hilft es ja.
 
Tests zu hal, k3b und dsbmd

Hallo,

das Testrepo mit dem aktuellen lde5 samt k3b, dsbmc, dsbmc-cli und dsbmd ist über Nacht fertig geworden, bei den Optionen habe ich darauf geachtet, dass hal bei den Subports von kde5 und bei k3b nicht gesetzt ist.
Hier die /usr/local/etc/poudriere.d/make.conf:
Code:
# build ports allways without X
WITHOUT_X11=yes
# default options
OPTIONS_UNSET= HAL BONJOUR DEBUG X11 PULSE
OPTIONS_SET= SNDIO
Das neue Repo beinhaltet kein hal-Paket.

Das hat schon mal geklappt, heute Abend werde ich damit mal ein Testsystem aufsetzen. Wenn allerdings k3b ohne hal dann schon scheitert, meine optischen Laufwerke zu erkennen, dann befürchte ich, dass ohne hal auch bei den neuesten Versionen von k3b nicht auszukommen ist.

Ich befürchte außerdem, dass schon unter kde4, altem k3b samt hal auch dsbmd komische Effekte hervorrufen kann, erst nach mehreren Anläufen gelang es mir gestern nämlich, eine Audio CD zu brennen, k3b ist zuvor ständig mit mir wenig sagenden Fehlermeldungscodes zu cdrdao und cdrecord ausgestiegen, ich werde auch da weiter herum probieren (vielleicht liegt es auch an was anderem).
 
Ich befürchte außerdem, dass schon unter kde4, altem k3b samt hal auch dsbmd komische Effekte hervorrufen kann, erst nach mehreren Anläufen gelang es mir gestern nämlich, eine Audio CD zu brennen, k3b ist zuvor ständig mit mir wenig sagenden Fehlermeldungscodes zu cdrdao und cdrecord ausgestiegen, ich werde auch da weiter herum probieren (vielleicht liegt es auch an was anderem).
Hast du mal versucht, das Polling von HAL abzustellen?
Code:
# hal-disable-polling --device /dev/cd0
Wäre ja schön, wenn DSBMD und HAL miteinander leben könnten, wenn man bei HAL das Polling abstellt.
 
Ich habe mich endlich dazu durchringen können, DSBMC dahingehend zu erweitern, dass man die Mount points, die man nicht sehen möchte (gvfs), in den Einstellungen angeben kann. Außerdem sollten sich DSBMC jetzt zuverlässig an seine vorherige Position und Größe erinnern. Über Tests würde ich mich freuen:

Code:
# fetch https://codeload.github.com/mrclksr/DSBMC/zip/master
# unzip master
# cd DSBMC-master && make install
Eines Tages müsste das eh mal in Qt5 portiert werden ...
 
Hast du mal versucht, das Polling von HAL abzustellen?
Hallo Marcel,

wenn ich das Polling - in meinem Falle cd1 - abstelle, gibt es das Laufwerk für k3b nicht mehr.

Aber ich werde dieses Wochenende eh mit meinem kleinen hal freien selbst gebauten Testrepo kde5, k3b und dsbmd mal eine separate Installation machen und dann nochmals ausprobieren, wie k3b dann mit optischen Laufwerken umgeht.
 
wenn ich das Polling - in meinem Falle cd1 - abstelle, gibt es das Laufwerk für k3b nicht mehr.
War ja irgendwie schon klar. Wenn ich nicht schon alle Hände voll zu tun hätte, würde ich mal in K3b rein schauen, ob man da nicht den HAL bezogenen Code ersetzen könnte.
Aber ich werde dieses Wochenende eh mit meinem kleinen hal freien selbst gebauten Testrepo kde5, k3b und dsbmd mal eine separate Installation machen und dann nochmals ausprobieren, wie k3b dann mit optischen Laufwerken umgeht.
Ich fürchte, es scheint da kein Weg an HAL vorbei zu führen, wenn man K3b benutzen möchte.
 
Aber ich werde dieses Wochenende eh mit meinem kleinen hal freien selbst gebauten Testrepo kde5, k3b und dsbmd mal eine separate Installation machen und dann nochmals ausprobieren, wie k3b dann mit optischen Laufwerken umgeht.

Wäre ja schön, wenn DSBMD und HAL miteinander leben könnten, wenn man bei HAL das Polling abstellt.

Nein, jetzt wo es dsbmd gibt, sollte es HAL völlig überlüssig machen.

Wäre da jetzt nicht langsam mal der Entwickler gefragt, den Ihr mal erwähnt hattet? Letzendlich gibt es HAL unter Linux schon lange nicht mehr, da muss k3b doch auch irgendwie anders funktionieren.

Und @holgerw, hast Du denn schon die Möglichkeit gehabt, das Verhalten von Dolphin mit Deinen ohne HAL kompilierten Paketen zu testen?
 
Nein, jetzt wo es dsbmd gibt, sollte es HAL völlig überlüssig machen.

Wäre da jetzt nicht langsam mal der Entwickler gefragt, den Ihr mal erwähnt hattet? Letzendlich gibt es HAL unter Linux schon lange nicht mehr, da muss k3b doch auch irgendwie anders funktionieren.

Und @holgerw, hast Du denn schon die Möglichkeit gehabt, das Verhalten von Dolphin mit Deinen ohne HAL kompilierten Paketen zu testen?

Hallo,

ich muss den ganzen inoffiziellen Krempel nochmals bauen. Ich habe offenbar unabsichtlich beim Modifizieren von x11/xorg die dbus-Unterstützung weg geklickt, damit startet kein plasma5, wie ich heute früh fest stellen durfte. :grumble:

Aber: Es gibt eine kleine Hoffnung: Beim Bau von plasma5 gibt es den Port kf5-solid, bei dem man anstelle von hal dann bsddisks für das Managen von Devices verwenden kann. Nun weiß ich noch nicht, ob sich das auch auf k3b auswirkt, allerdings wurde bei dem Bau meines Repos kein hal Paket gebaut (wäre da nicht die doofe fehlende dbus-Sache von xorg).

Ich bleibe dran, bitte aber um Geduld, da ich momentan wenig Freizeit habe.
 
Einen neuen Thread will ich nicht öffnen und es passt auch gut hierher.

In letzter Zeit musste ich mehrfach .iso-Files mounten, verändern und wieder brennen (siehe auch https://www.bsdforen.de/threads/bootable-dvd-erstellen.34465/ ). Da habe ich es genossen, wenn DSBMC als Reaktion auf das erstellte md-Gerät öffnete, mir das Gerät vorgab und ich per Mausklick mounten konnte.
Allerdings kam mir dabei auch die Idee, ob man nicht DSBMC irgendwie direkt das .iso vorsetzen könnte und ihm alles überlassen, also auch das Anlagen und spätere Zerstören der md-Geräte.

Wie man das machen kann, ist mir etwas unklar. Rechter Maus-Klick wäre natürlich schön, oder drag_n_drop ins DSBMC-Fenster mit anschließendem Dialog oder einfach eine Möglichkeit, innerhalb des DSBMC-Fensters auf "ISO-Mounten" oder etwas in der Art zu klicken und dann den Pfad zu dem gewünschten .iso zu setzen und eben DSBMC alles machen zu lassen.

Klar, das kommt nicht alle Tage vor, aber gerade dann ist ja eine Automatik so vorteilhaft, weil man nicht immer wieder erst die man-pages lesen muss.
Und weil FreeBSD hier gegenüber GNU die Option -o loop fehlt, oder wie das nochmal genau war, können isos ja nicht direkt eingebunden werden und erfordern eben den Umweg über das md-Gerät.

Also, für mich schreit das geradezu nach einem Automatismus und am liebsten integriert in meinen Standard-Mount-Mechanismus.

Seht ihr vielleicht auch einen Bedarf?
@marcel : siehst du vielleicht eine einfache Möglichkeit, so etwas einzubauen? Quasi, mir zu Gefallen, wenn sonst niemand so etwas braucht.
 
Hallo @pit234a,
Allerdings kam mir dabei auch die Idee, ob man nicht DSBMC irgendwie direkt das .iso vorsetzen könnte und ihm alles überlassen, also auch das Anlagen und spätere Zerstören der md-Geräte.
Im Moment bin ich dabei, die Version 1.4 in die Ports zu bringen. Diese erlaubt es zumindest schon mal, dass Du per eject in DSBMC oder DSBMC-Cli das md-Gerät zerstören (detachen) kannst. Was das Anlegen eines md-Geräts betrifft, da muss ich mal drüber nachdenken.
 
@pit234a
So wie sich das liest, kommt das unter Windows den daemon-tools sehr nahe. Wenn du das so meinst, dann wäre ich da sehr dafür, das umzusetzen!
Ungemein praktisch!
 
@pit234a
So wie sich das liest, kommt das unter Windows den daemon-tools sehr nahe. Wenn du das so meinst, dann wäre ich da sehr dafür, das umzusetzen!
Ungemein praktisch!
Das weiß ich nicht, kenne mich da noch weniger aus.
In unseren Windows-Rechnern kann man mit 7Zip (oder so ähnlich) ein iso quasi extrahieren und bekommt so an einem neuen Speicherplatz den Inhalt des .iso präsentiert.
Im Grunde ist es das, was ich machte. Oder so ähnlich.

Wie das in GNU/Linux geht, weiß ich gerade auch nicht, aber da braucht man keine md-Geräte und kann iso-Files direkt (mit einer entsprechenden Option) mounten. Damit hat man dann die Möglichkeit, diese zu browsen, sie sind aber nicht "entpackt". Möglicherweise gibt es dazu auch grafische Tools oder Automatismen, das weiß ich eben nun nicht. Also, ohne zu "entpacken" und alles an einem neuen Ort zu extrahieren, kann man aber, was man möchte, aus dem Mount-Verzeichnis, in ein neues Verzeichnis kopieren oder, wie in meinem Fall gewünscht, eine Auswahl der Dateien des iso dem Brennprogramm mitgeben, um eine neue und diesmal etwas kleinere DVD zu erstellen.
Was ich in FreeBSD gemacht habe, war exakt dies:
ein md-Gerät auf ein iso angelegt (manuell), dieses gemountet (mit DSBMC), dem Brennprogramm aus dem Mount-Verzeichnis eine Auswahl von Dateien hin-geschoben (das ganze bootbar gemacht) und daraus eine neue DVD gebrannt. Das Gerät ausgehangen (mit DSBMC) und dann das md-Gerät zerstört (manuell).

Man sieht sofort, dass der Mix aus manuellem Vor- und Nachbereiten mit der Nutzung eines Automatismus irgendwie unelegant rüber kommt. Das ist nicht vollkommen stringent. Es geht. Und DSBMC erspart mir immerhin zwei Zeilen zum Eingeben, wenn ich alles manuell machen müsste.

Deshalb kam mir die Idee, danach zu fragen, die Vor- und Nachbereitung auch maschinell und nicht mehr manuell zu erledigen.

Ist das in etwa, was diese Windows daemon-tools machen?
 
Zurück
Oben