Announcement: there is an English version of this forum on 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.
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
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.
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.
> Es gibt keine Warnungen, nur Fehlermeldungen und Abbruch.
Im Sabotagefall kaeme noch das Triggern einer externen Crowbar in
Betracht.
Mit udev regeln (wenn usb stick oder Mmc, dann script ausführen) kannst du sowas erledigen. Zumindest unter debian.
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.
:
Bearbeitet durch User
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
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 ;)
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?
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.
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...
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?
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.
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
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.
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.
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.
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
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.
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
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.
MaWin O. schrieb: > Was bringt uns dieses Copy&Paste-Googleergebnis nun? das funktioniert...
:
Bearbeitet durch User
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!
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.
C-hater schrieb: > Aber die Sprache (und ihre Erben) ist und bleibt immanent unsichere > Scheiße. Da kann ich dir sogar zu 110% zustimmen.
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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.