Forum: PC-Programmierung wie findet man das Device zum USB-Stick?


von Bauform B. (bauformb)


Lesenswert?

Mahlzeit!

Früher war /dev/sda die Festplatte und /dev/sdb der USB-Stick, oder 
höchstens mal /dev/sdc. Mit eMMC, nvme usw. wird das mounten etwas 
komplizierter.

Die "beliebte" UUID nützt garnichts, die des USB-Sticks kann ich ja 
nicht kennen. blkid -c /dev/null liefert auch nichts eindeutiges. Ein 
passender udev-Event ist vielleicht schon vorgestern passiert (oder noch 
nicht). Irgendeine Art von automount verschiebt nur das Problem vom 
Device zur Partition. Außerdem will ich nur read-only mounten.

Also kann mein Programm nur alle Partitionen in /proc/partitions 
versuchsweise mounten und die entscheidende Datei suchen? Gibt es eine 
bessere Strategie?

Die Aufgabe ist, dass der Benutzer eine config-Datei per USB-Stick oder 
(hoffentlich nicht) per SD-Karte mitbringt und einspielt. Den Moment des 
Ansteckens erwischt mein Programm nicht unbedingt, also muss ich suchen.

von Norbert (der_norbert)


Lesenswert?

1
lsblk oder
2
lsblk -lf
 wird zur Erleuchtung beitragen.

Aber wenn du weder weißt was der Benutzer eingesteckt hat, noch wann er 
es getan hat, noch ob die Partition einen bestimmten Typ hat, noch ob es 
ein LABEL oder eine UUID gibt, dann wird es wohl auf eine Suche hinaus 
laufen.

: Bearbeitet durch User
von Thomas W. (Gast)


Lesenswert?

Vor allen Dingen kann es ja sein, dass der Benutzer mehr als eine 
Konfigurationsdatei auf dem (nicht spezifizierten) Wechseltraeger 
gespeichert hat.

So lustig die Idee ist ("Der USB-Zuendschluessel") so unpraktisch ist 
sie auch.

Gruesse

Th.

von Bauform B. (bauformb)


Lesenswert?

Norbert schrieb:
> lsblk wird zur Erleuchtung beitragen.

In der Tat, das ist etwas für's Auge :)
1
lsblk --output 'NAME,TRAN,MOUNTPOINTS'
liefert sata/mvme/usb... Mit kleinen Einschränkungen wäre schon viel 
weniger zu durchsuchen: / befindet sich auf keinen Fall auf USB und die 
config-Datei auf jeden Fall. Ein SD-Karte im externen Kartenleser wird 
hier auch unter usb gelistet. Dafür hat ein Luxuskartenleser gleich ein 
Dutzend devices.

Weder aus dem Dateisystem noch aus der Größe kann man heutzutage 
irgendwas schließen. USB oder nicht bleibt wohl das einzige Kriterium.


Thomas W. schrieb:
> Vor allen Dingen kann es ja sein, dass der Benutzer mehr als eine
> Konfigurationsdatei auf dem (nicht spezifizierten) Wechseltraeger
> gespeichert hat.

Noch böser: zwei USB-Sticks, beide mit einem gültigen Dateinamen ;) Aber 
sowas grenzt alles an Sabotage und wird einfach verweigert. In der 
Hinsicht habe ich weniger Bedenken. Ich bastel ja keinen Browser, der 
jeden Müll irgendwie anzeigen will. Es gibt keine Warnungen, nur 
Fehlermeldungen und Abbruch.

von Motopick (motopick)


Lesenswert?

> Es gibt keine Warnungen, nur Fehlermeldungen und Abbruch.

Im Sabotagefall kaeme noch das Triggern einer externen Crowbar in 
Betracht.

von Jörg E. (jackfritt)


Lesenswert?

Mit udev regeln (wenn usb stick oder Mmc, dann script ausführen) kannst 
du sowas erledigen. Zumindest unter debian.

von Stefan F. (Gast)


Lesenswert?

Ich gebe den Dateisystemen auf meinen USB Speichermedien aussagekräftige 
Namen, die erscheinen dann auch im Dateimanager.

Unter Linux geht das z.B. mit gparted, nachdem man das Medium 
"ausgehängt" hat.

von Frank K. (fchk)


Lesenswert?

Bauform B. schrieb:

> Ein SD-Karte im externen Kartenleser wird
> hier auch unter usb gelistet. Dafür hat ein Luxuskartenleser gleich ein
> Dutzend devices.

Und ein interner Kartenleser entweder als USB oder als mmcblk, je nach 
Controllerhardware - und das auch auf PC-Hardware.

Andere Tools wie z.B. Clonezilla machen es so, dass man den externen 
Datenträger erst entfernen muss und dann erst nach Aufforderung 
einstecken darf. Damit reduziert sich das ganze auf einen 
vorher/nachher-Vergleich.

fchk

von Bauform B. (bauformb)


Lesenswert?

Stefan F. schrieb:
> Ich gebe den Dateisystemen auf meinen USB Speichermedien aussagekräftige
> Namen, die erscheinen dann auch im Dateimanager.
> Unter Linux geht das z.B. mit gparted, nachdem man das Medium
> "ausgehängt" hat.

Ja, und iOS gibt es auch noch; das ist eine andere Welt, davon träume 
ich nicht einmal.

Frank K. schrieb:
> Und ein interner Kartenleser entweder als USB oder als mmcblk

Das wird per Verordnung geregelt: keine internen Kartenleser. Wer einen 
USB-Leser mitbringt, darf den benutzen. Wahrscheinlich funktionieren 
auch externe Festplatten, für die, die es besonders umständlich mögen. 
Damit reduziert sich das Ganze auf sd* und falls / auch auf sd wohnt, 
wird das Gerät ausgeklammert.

Motopick schrieb:
> Im Sabotagefall kaeme noch das Triggern einer externen Crowbar in
> Betracht.

Bei größeren Schaltanlagen gibt es ja Motortrenner, aber der 
Erdungsschalter ist zu gut verriegelt ;)

von Norbert (der_norbert)


Lesenswert?

Bauform B. schrieb:
> Das wird per Verordnung geregelt: keine internen Kartenleser. Wer einen
> USB-Leser mitbringt, darf den benutzen. Wahrscheinlich funktionieren
> auch externe Festplatten, für die, die es besonders umständlich mögen.
> Damit reduziert sich das Ganze auf sd* und falls / auch auf sd wohnt,
> wird das Gerät ausgeklammert.

Werden denn nicht alle vom Benutzer eingesteckten Geräte/Block-Devices 
automagisch unter ›/media/<user>‹ gemountet?

von Bauform B. (bauformb)


Lesenswert?

Norbert schrieb:
> Werden denn nicht alle vom Benutzer eingesteckten Geräte/Block-Devices
> automagisch unter ›/media/<user>‹ gemountet?

Nein, sowas gibt es hier nicht. Nach dem Motto: trau keiner Automatik, 
die du nicht selbst programmiert hast. Ja, wahrscheinlich würde es 
meistens sogar funktionieren. Aber wenn nicht, ist der Fehler schwerer 
zu finden.

von C-hater (c-hater)


Lesenswert?

Bauform B. schrieb:

> Nein, sowas gibt es hier nicht. Nach dem Motto: trau keiner Automatik,
> die du nicht selbst programmiert hast.

Ich würde definitiv eher dazu neigen, den gut getesteten Automatiken der 
Desktop-Umgebungen zu trauen, als irgendetwas, was du verbrochen hast...

Nichtsdestotrotz gibt es tatsächlich Umgebungen, in denen ich diese 
Komfortfunktion abschalte. Z.B. bei meinem Linux-Datenrettungs- und 
Forensik-Stick. In dessen Einsatzbereich ist Auto-Mount natürlich 
tatsächlich eher kontraproduktiv...

von MaWin O. (mawin_original)


Lesenswert?

C-hater schrieb:
> bei meinem Linux

Sag bloß, du hast ein C-Programm im Einsatz!

von Reinhard S. (rezz)


Lesenswert?

Bauform B. schrieb:
> Device zur Partition. Außerdem will ich nur read-only mounten.
>
> Also kann mein Programm nur alle Partitionen in /proc/partitions
> versuchsweise mounten und die entscheidende Datei suchen? Gibt es eine
> bessere Strategie?

Die Liste von /dev/sdX abklappern und einfach das letzte Gerät nehmen?

von Rolf M. (rmagnus)


Lesenswert?

Reinhard S. schrieb:
> Die Liste von /dev/sdX abklappern und einfach das letzte Gerät nehmen?

Passt nicht zwingend. Sagen wir mal, du steckst einen USB-Stick ein, und 
der wird sda. Jetzt steckst du einen zweiten ein, dann wird der sdb. 
Wenn du dann den ersten wieder aussteckst und dafür einen dritten 
einsteckst, bekokmmt dieser jetzt den Namen sda, und sdb ist immer noch 
der davor eingesteckte.

von MaWin O. (mawin_original)


Lesenswert?

Unter /sys/block/ gibt es alle möglichen Informationen zu den 
Blockgeräten. z.B. auch 'removeable'. Irgendeine Art von Information 
über die Eigenschaft des Speichersticks wirst du wohl annehmen müssen. 
Sonst bleibt nur die Möglichkeit alle zu mounten und nachzuschauen.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

MaWin O. schrieb:
> Unter /sys/block/ gibt es alle möglichen Informationen zu den
> Blockgeräten. z.B. auch 'removeable'.

Ja, und vor allem 'usb'. Allerdings traue ich dem 'removeable' nicht. Es 
gab mal das Problem, dass sich irgendwelche Datenträger mit und ohne 
removeable Flag melden konnten - ohne erkennbare Systematik. Man könnte 
das näher untersuchen, aber was soll's.

Inzwischen bin ich sicher, dass USB-Massenspeicher ein /dev/sd* 
benutzen, von wegen SCSI-Befehlssatz. Wenn ich dann noch das ganze Gerät 
mit der root-Partition ausschließe, bleibt ungefähr das Richtige übrig. 
Wenn jemand die Daten auf einer externen Festplatte bringt, geht das 
auch. Und wenn auf dem Umweg über einen Adapter kein /dev/sd* benutzt 
wird, ist es auch nicht tragisch.

Der Anlass für die Frage war ein PC mit sata, PCIe, eMMC, SD-Kartenleser 
und natürlich USB. Da wollte ich nicht große, langsame Partitionen 
sinnlos durchsuchen.

von MaWin O. (mawin_original)


Lesenswert?

Wie viele block devices hast du denn, die nicht gemountet sind? Wenn der 
Nutzer einen Stick einsteckt, sollte das doch in der Regel das einzige 
nicht gemountete Gerät sein. Und dann hast du es gefunden.
Ich würde einfach nach nicht gemounteten Geräten filtern und die dann 
durchsuchen.

von MaWin O. (mawin_original)


Lesenswert?

Und nach Dateisystemen würde ich wahrscheinlich auch noch filtern, bzw 
nur einige wenige erlauben. FAT/exFAT sollten ja die gängigen sein auf 
Sticks. Wenn man ein Gerät mit FAT/exFAT findet, dann ist das ja 
praktisch garantiert vom Nutzer eingesteckt.

von Bauform B. (bauformb)


Lesenswert?

MaWin O. schrieb:
> Wenn der Nutzer einen Stick einsteckt, sollte das doch in der Regel
> das einzige nicht gemountete Gerät sein.

MaWin O. schrieb:
> Wenn man ein Gerät mit FAT/exFAT findet, dann ist das ja
> praktisch garantiert vom Nutzer eingesteckt.

UEFI hat quasi eine eigene FAT-Partition und die wird im Betrieb nicht 
benutzt.

Die Einschränkung mit FAT/exFAT kann man machen, aber es wäre eine 
künstliche Einschränkung, das macht man doch nicht freiwillig. Ja, ich 
weiß, Lochstreifen gehen auch nicht, aber was ist, wenn jemand mit ZFS 
daher kommt :)

https://unix.stackexchange.com/questions/659073/is-there-a-way-to-access-zfs-formatted-usb-stick-in-linux

von MaWin O. (mawin_original)


Lesenswert?

Bauform B. schrieb:
> Die Einschränkung mit FAT/exFAT kann man machen, aber es wäre eine
> künstliche Einschränkung, das macht man doch nicht freiwillig.

Würde ich freiwillig auch aus anderen Gründen schon machen. Dateisysteme 
sind riesige Angriffsflächen für ausnutzbare Bugs. Alleine schon aus 
diesem Grund würde ich die nutzbaren Dateisysteme generell auf wenige 
einschränken.

> UEFI hat quasi eine eigene FAT-Partition und die wird im Betrieb nicht
> benutzt.

Aber die sollte sich ja auch einfach ausfiltern lassen.

von B. P. (skorpionx)


Lesenswert?

im PC mit Windows:

CMD USB Stick reparieren
Kurzanleitung: Eingabeaufforderung

    Drücken Sie [Windows] + [R] und geben Sie cmd ein. ...
    Geben Sie nun "diskpart" ein.
    Mit "list disk" listen Sie alle Datenträger auf.
    Mit "select disk 1" wählen Sie z.B. Disk 1
    Mit "clean" können Sie nun den USB-Stick sauber machen
    Mit  "create partition primary" wird neue partition angelegt

von Bauform B. (bauformb)


Lesenswert?

MaWin O. schrieb:
> Würde ich freiwillig auch aus anderen Gründen schon machen. Dateisysteme
> sind riesige Angriffsflächen für ausnutzbare Bugs. Alleine schon aus
> diesem Grund würde ich die nutzbaren Dateisysteme generell auf wenige
> einschränken.

OK, das ist ein Argument. Nicht so sehr wegen Angriffen, aber wegen 
Bugs. Ein Angreifer muss immerhin noch seine eigene Tastatur mitbringen, 
aber dann gehört ihm der Rechner.

von MaWin O. (mawin_original)


Lesenswert?

B. P. schrieb:
> Kurzanleitung

Was bringt uns dieses Copy&Paste-Googleergebnis nun?

von B. P. (skorpionx)


Lesenswert?

MaWin O. schrieb:
> Was bringt uns dieses Copy&Paste-Googleergebnis nun?

das funktioniert...

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

B. P. schrieb:
> das funktioniert...

Aha. Und welche Frage beantwortet es?

von Bauform B. (bauformb)


Lesenswert?

B. P. schrieb:
> das funktioniert...

Iglo vegetarische Lasagne:
 - die Plastikfolie mehrmals einstechen
 - das tiefgefrorene Gericht in die Mikrowelle stellen
 - bei 800 Watt für ca. 17 Minuten erhitzen
 - das Gericht aus der Mikrowelle nehmen
 - für ca. 1-2 Minuten abkühlen lassen
 - dann vorsichtig die Plastikfolie abziehen und genießen

Funktioniert noch besser!

von C-hater (c-hater)


Lesenswert?

MaWin O. schrieb:
> C-hater schrieb:
>> bei meinem Linux
>
> Sag bloß, du hast ein C-Programm im Einsatz!

Eins? Tausende.

Ich schreibe sogar selber welche.

Aber die Sprache (und ihre Erben) ist und bleibt immanent unsichere 
Scheiße.

von MaWin O. (mawin_original)


Lesenswert?

C-hater schrieb:
> Aber die Sprache (und ihre Erben) ist und bleibt immanent unsichere
> Scheiße.

Da kann ich dir sogar zu 110% zustimmen.

von Michi S. (mista_s)


Lesenswert?

Bauform B. schrieb:
> Die Einschränkung mit FAT/exFAT kann man machen, aber es wäre
> eine künstliche Einschränkung, das macht man doch nicht
> freiwillig.

Woran erkennst Du eigentlich Deine config-Datei? Doch nicht etwa am 
Dateinamen? Das ist dann keine künstliche Einschränkung?

Der einzige Weg, künstliche Einschränkungen komplett zu vermeiden, wäre 
doch einfach den Benutzer zu fragen.


Bauform B. schrieb:
> Allerdings traue ich dem 'removeable' nicht. Es
> gab mal das Problem, dass sich irgendwelche Datenträger mit
> und ohne removeable Flag melden konnten

Wenn Du lange genug suchst, findest Du sicher auch noch USB-Sticks, die 
sich nicht als /dev/sdX einordnen.

Wie wäre es, all diese Kriterien nicht absolut anzuwenden, sondern 
dadurch nur Deine Suchreihenfolge zu beeinflussen: also zuerst auf 
removeable /dev/sdX mit FAT/exFAT Filesystem suchen mit X in 
absteigender alphabetischer Reihenfolge, dann die übrigen FS, die nicht 
removeable Devices usw...

Damit hast Du vermutlich in 99% der Fälle (08/15 USB-Stick, zuletzt 
eingsteckt) beim ersten Versuch bereits Deinen Treffer; die nächsten 
0,99% deckst Du mit den ersten paar Versuchen ab, aber für die 
pathologischen Fälle findest Du Dein Config-File auf allem, was das 
Kernel auch nur irgendwie als Blockdevice abbildet.

von Bauform B. (bauformb)


Lesenswert?

Michi S. schrieb:
> Woran erkennst Du eigentlich Deine config-Datei? Doch nicht etwa am
> Dateinamen? Das ist dann keine künstliche Einschränkung?

Ein sehr guter Einwand. Anscheinend gibt es gute und böse 
Einschränkungen.

> Der einzige Weg, künstliche Einschränkungen komplett zu vermeiden, wäre
> doch einfach den Benutzer zu fragen.

Bisher kann der Benutzer die "komplizierten" Aufgaben, z.B. richtige 
Dateinamen benutzen, am eigenen PC erledigen und braucht dann an meiner 
Kiste nur noch 1 Mausklick. Einschränkungen machen das Leben leichter ;)

Von wegen Dateinamen: nachdem das Format ganz streng geregelt ist, 
sollte man meinen, dass durchgehend Kleinbuchstaben benutzt werden. 
Tatsächlich liefern Windows-Benutzer jede Mischung ab. Erster 
Buchstabe groß wäre ja verständlich, aber mitten drin? Oder Name klein 
und Endung groß. Oder Endung mit großem Anfangsbuchstaben. Kein Problem, 
aber faszinierend.

> Wie wäre es, all diese Kriterien nicht absolut anzuwenden, sondern
> dadurch nur Deine Suchreihenfolge zu beeinflussen: also zuerst auf
> removeable /dev/sdX mit FAT/exFAT Filesystem suchen mit X in
> absteigender alphabetischer Reihenfolge

Raffiniert. Ja, jede Millisekunde zählt. Im Ernst, wenn man nicht 
aufpasst, wird die Reaktionszeit auf den Mausklick zu lang. Sowas hasse 
ich besonders gerne.

: Bearbeitet durch User
von C-hater (c-hater)


Lesenswert?

Bauform B. schrieb:

> Von wegen Dateinamen: nachdem das Format ganz streng geregelt ist,
> sollte man meinen, dass durchgehend Kleinbuchstaben benutzt werden.
> Tatsächlich liefern Windows-Benutzer jede Mischung ab.

So what? Unter Windows spielt das ja auch keine Rolle. Wenn du also 
Dateien von Windows-Nutzern erwartest (die diese darüber hinaus mit 
irgendwelchen unbekannten Tools erzeugen, die deine strenge 
Formatregelung überhaupt nicht kennen) , dann musst du halt einfach 
darauf vorbereitet sein, Dateinamen auch dann zu finden, wenn sie 
case-independend sind.

Das ist dein verdammter Job als Programmierer. Ende der Ansage.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.