"Ob die Warnung, dass es mit FAT zu Datenverlusten kommen kann, wenn man vergisst, »sync« aufzurufen, weil Linux das Dateisystem nicht synchron mounten kann, noch Gültigkeit hat, ist mir nicht bekannt. Mir ist es egal, da die Daten auf einem USB-Medium ersetzbar sind."
Sorry aber was ist das denn für ein Artikel? "ist mir egal"...
Ohne jemandem zu nahe treten zu wollen, prolinux ist eine schöne Seite, die ich gern besuche und an die ich hin und wieder auch gern Hinweise schicke; auch leisten die Admins super Arbeit, noch dazu in ihrer Freizeit, aber:
99,9% der User wollen, wenn sie ihre Daten auf ihren USB-Stick schieben, diese dann auch sicher dort haben (egal, ob sie die Daten selbst noch auf Platte haben, aber i.d.R. will man sie so doch irgendwo hin mitnehmen - und dann sieht es ganz blöd aus, wenn die Daten nicht da sind).
Leider muss ich mich dem Vorposter anschließen: Besser den Artikel überarbeiten oder löschen.
99,9% der User wollen, wenn sie ihre Daten auf ihren USB-Stick schieben, diese dann auch sicher dort habenÄh, dann sollte man mal 99,9% der User erzählen, wie unsicher der Stick (-> Flash-Speicher!!!) als Speichermedium wirklich ist. Ich kenne allein zwei Leute, denen die mp3-Sammlung abhanden gekommen wäre, wenn sie sie nicht zusätzlich auf der Festplatte gehabt hätte. Wobei die Daten natürlich trotzdem sicher auf das USB-Medium geschrieben werden müssen, man darf halt die Sicherung auf der Festplatte nicht vergessen.
Das ist mir neu. Kann es sein, dass die beiden einfach ihre USB-Geraete nicht immer sicher ausgehaengt haben? BTW: Wenn ich auf meinem Linuxdesktop (2.6.xx) meine Digitalkamera "umounte", und das Kommando bereits beendet ist, blinkt auf der Kamera noch immer das Send/Receive-LED. Ich finde das etwas beaengstigend
Es versteht sich doch von selbst, dass man das Dateisystem unmounten muss, bevor man den Stick abzieht. Ich sehe jetzt nicht, wo im Artikel etwas unklar sein soll.
dass man FS allgemein umounten muss wird erwähnt, dass ist es nicht.
Der Punkt ist: Es geht einfacher und sicherer - bei heutigen Automountern (die es auch unabhängig von Desktop-Umgebungen gibt) kann man den Stick anstecken und abziehen ohne sich Gedanken um mount/umount machen zu müssen und die Daten sind trotzdem sicher. Der Artikel hinkt in puncto Komfort und Datensicherheit leider dem Stand der Linux-Technik hinterher.
Bitte nimm das und auch die anderen Kommentare hier auf keinen Fall persönlich! Du machst seit vielen Jahren schon einen wirklich guten Job, der Respekt verdient!
Ja natürlich muss man warten, bis die Schreiboperation abgeschlossen ist (was bei sync gemounteten FS identisch ist mit dem sichtbaren Abschluss der Operation im GUI/CLI).
Die "sync" Option ist die bste Methode den USB-Stick zu beschaedigen.
Ein heutiger Flash Speicher kann die grosse Anzahl der Schreibvorgaenge die beim FAT Dateisystem im "Inhaltsverzeichnis" gemacht werden nicht verkraften. Man braucht in der Regel einen 1 GB grossen Stick nur 2 - 3 mal vollschreiben wenn "sync" an ist, und der Speicher ist hinueber.
Das gilt natuerlich nicht fuer Festplatten, die kann man "sync" mounten.
Dieses Verhalten von Flash Speicher ist uebrigens auch der Grund dafuer, dass es unter Windows das "sichere Aushaengen" von USB Speicher gibt, Microsoft koennte auch viel Nutzerfreundlicher sein und den Speicher synchron mounten.
Lasst euch das von jemandem sagen, der bereits 2 USB-Sticks auf diese Art verheizt hat. Ich habe aus meinen Fehlern gelernt, bitte tut das auch.
Das Problem bestand vor 100 Jahren mal. Bitte passe mal dein Wissen an aktuelle Gegebenheiten an. Heutige USB-Medien verteilen die Schreiboperationen gleichmäßig und ersetzen im Hintergrund auch defekte Blöcke.
OK... kein Problem. Dieses Tool ist nicht für jeden, aber es ist eine Alternative für Leute, die aus diesem oder jenem Grund keinen anderen Automounter einsetzen. So sollte das eigentlich verstanden werden, und ich dachte, das sei klar genug geschrieben.
"usbmount erlaubt es, USB-Laufwerke unabhängig von einer Desktop-Umgebung automatisch zu mounten."
Das ist schön, danke für den Tipp.
Unter Kernel 2.4 klappte das mit Hotplug allerdings auch schon ohne Probleme, vor allen Dingen desktopunabhängig und sogar auf einem reinen Konsolensystem. Jedenfalls unter Suse 9.0. Der angeschlossene Stick war jedenfalls immer unter /media/sdax (z.B. /media/sda1) zu finden.
Irgendwie scheint es da zwischenzeitlich einen Rückschritt gegeben zu haben.
Und wenn man dann nach der ivman-Installation wieder unter einer OpenSuse KDE startet, dann hat man dann wohl leider zwei Programme, die sich um einen USB-Stick kümmern möchten?
Das "automagisch" bzw. "automatisch" meinte ich eigentlich gar nicht. Mir ging es um das "desktopunabhängig" und dass ich Zugriff auf den USB-Stick habe, ohne an irgendeiner Konfigurationsdatei nacharbeiten zu müssen. Genau das klappt bei Suse 9.0, Kernel 2.4 (2.4.21-303) mit Hotplug, Konsolensystem (init 3). USB-Stick anstecken, es ertönt ein Signal. Danach "mount sda1" eingeben und man kann auf der Konsole auf den Stick zugreifen. Ich muß nicht noch extra einen ivman oder Ähnliches installieren. Suse 9.0 hält den Stick systemweit unter /media/sda1 (bzw. /media/sdax) mountbar bereit. Die fstab ist dazu von Suse entsprechend automatisch geändert worden. Warum das so klappt? Ganz einfach: Der USB-Stick wird eingesteckt und hotplug kreiert einen temporären Eintrag für den Stick in der fstab.
KDE- oder Gnome-Installationen moderner Linuxe machen zunächst Probleme, wenn man danach einfach nur bis zur Konsole (init 3) durchstartet, d.h. KDE bzw. Gnome überhaupt nicht startet. Es wird auf der Konsole angezeigt, dass der USB-Stick erkannt wurde, aber ich kann ihn zunächst nicht mounten. Erst wenn ich z.B. von Hand die fstab entsprechend ändere, dann klappt das wieder. Ein einfaches "mount ..." reicht zunächst nicht, unter /media z.B. ist kein entsprechender Eintrag zu finden.
Ich bin damit also in diesem Fall heutzutage meistens ein kleines Stückchen schlechter dran als noch unter Suses altem 2.4-Kernel, insofern ich rein nur auf der Konsole arbeite oder eine alternative, schlanke Desktopumgebung wie etwa Fvwm benutze.
Die hotplug Skripte in Suse waren ein Krampf und sind nicht ohne Grund obsolet geworden. Oder konntest Du das "mount /dev/sda1" mit Userrechten aufrufen?
Seit 2.6 gibt es HAL und DBUS in alles Distributionen. Da ist es doch nur von Vorteil Programme wie ivman zu nutzen, die diese offiziellen Technologien unterstützen.
Und wenn man doch eine fette Desktop-Umgebung startet, wird da nichts doppelt gemacht. KDE und Gnome reagieren auch nur auf HAL- und DBUS-Events.
"Oder konntest Du das "mount /dev/sda1" mit Userrechten aufrufen?"
Ja, nur mit Userrechten. Rootrechte sind nicht erforderlich. Falls eine Desktopumgebung vorhanden ist, die Icons auf der jeweiligen Oberfläche unterstützt (z.B. KDE 3.1), so erscheint nach dem Einstecken des Sticks ein Icon mit dem Namen "sda1". Man muß allerdings noch mounten, d.h. in diesem Fall einfach draufklicken. Wird der Stick abgezogen, verschwindet das Icon wieder.
Warum nimmt man nicht den Kernel-eigenen automounter? Funktioniert bei mir perfekt sowohl für USB, also auch netzwerk geräte etc. Das einizge was ich noch nicht ganz gefixt bekommen habe, dass, falls ein Netzlaufwerk (per nfsv3) nicht verfügbar ist und der server down, dann dauert die reaktion etwas und solange blockiert leider jeder Dateimanager. Bei USB-Geräten liegt die Reaktion natürlich im millisekunden bereich und ist somit nicht merkbar. Aber wie das mit dem Aushängen ist weiß ich aber auch nicht aber da ich die dafür nötigen Devices nur read-only mounte ist die gefahr nicht gegeben. ^^
Mit automount sollte es auch gehen, habe es aber mit USB noch nicht gemacht. Üblicherweise stellt man den Automounter so ein, dass er nach einer kurzen Zeit der Inaktivität von selbst unmountet. Aber wenn man sicher sein will, dass alle Daten korrekt geschrieben sind, muss man dabei auch aufpassen, dass man den Stick nicht vorzeitig abzieht.
Ich lese eigentlich sehr gern PL aber ich weiß wirklich nicht was ich von diesem Artikel (...ist mir nicht bekannt... ,..Mir ist es egal... usw.) halten soll.
Diese Frage hätte nur den Fall betroffen, dass man das Unmounten vergisst, was man eh nie tun sollte. Aber auch bei vfat gibt es inzwischen das synchrone Mounten, deshalb habe ich den Text geändert.
Du wirst schon verstehen, dass alle daran abgehen, dass Du da im Grunde schreibst "Mir doch egal ob der Scheiß nu auf dem Stick is oder nich..." (hihi). Trotzdem an dieser Stelle auch von mir einen riesen-Dank für all die gute Arbeit, uns Nerds mit all den News, Tipps und Comments zu versorgen, die manchmal wichtiger sind als das "täglich Brot". Gruß auch an demon, der dem natürlich in Nix nachsteht. Jeder schießt mal nen Bock und heute warste einfach dran :).
ist nicht udev und hal die beste loesung ? hab das vor zig monaten mal gemacht, funzt einwandfrei und sogar mit festem mountpoint fuer den speicher, wenn man will
oder hab ich ein programm vergessen, welches da noch mitspielt?
Nein. Es reicht, in /etc/udev/rules.d/ in einer der Dateien den Stick / die Platte anzugeben.
Klar, ist natürlich nicht so bequem wie der gnome-volume-manager. Auf der anderen Seite hält sich die Zahl meiner USB-Sticks in Grenzen und so wird jedes Gerät automatisch an einem bekannten Speicherort eingehängt, so daß man da auch Skripte drüberlaufen lassen kann.
wie schon "default" schreib man brauch nur hal und udev unter debian installier ich einfach hal und mit den abhägigkeiten kommt auch udev mit, aber kein gnome (oder änlicher) volumen-manager
In /etc/udev/rules.d/ herumzurühren, ist aber nicht Sinn der Sache. Die udev-Regeln sind letztlich nicht als Konfigurationsdateien gedacht. Deswegen werden sie auch von /etc nach /lib verschoben werden, um u.a. das zu unterstreichen.
Netter Artikel. Was noch zu erwähnen ist, dass sich mit Hilfe von usbmount auch kinderleicht Skripte bei einem mount/umount aufrufen lassen, welche praktische Variablen wie $UM_MOUNTPOINT, $UM_DEVICE, $UM_FILESYSTEM (und ein paar mehr) zur Verfügung stellen.
Zu den anderen Kommentaren: Sync ist bei den Mountoptionen per standard aktiv und im Artikel wird lediglich auf die Warnung des Entwicklers in der Konfigurationsdatei eingegangen.
Btw. Das ganze eignet sich sehr gut um USB-Sticks zu kopieren... USB-Stick ran -> Skript aufruf -> Wenn fertig ein `beep` -> Abziehen Besonders schön, wenn man mal eben keinen X-Server oder Tastatur zur Hand hat. (Zb. MediaCenterPC)
Sorry aber was ist das denn für ein Artikel? "ist mir egal"...
99,9% der User wollen, wenn sie ihre Daten auf ihren USB-Stick schieben, diese dann auch sicher dort haben (egal, ob sie die Daten selbst noch auf Platte haben, aber i.d.R. will man sie so doch irgendwo hin mitnehmen - und dann sieht es ganz blöd aus, wenn die Daten nicht da sind).
Leider muss ich mich dem Vorposter anschließen: Besser den Artikel überarbeiten oder löschen.
BTW: Wenn ich auf meinem Linuxdesktop (2.6.xx) meine Digitalkamera "umounte", und das Kommando bereits beendet ist, blinkt auf der Kamera noch immer das Send/Receive-LED. Ich finde das etwas beaengstigend
dass man FS allgemein umounten muss wird erwähnt, dass ist es nicht.
Der Punkt ist: Es geht einfacher und sicherer - bei heutigen Automountern (die es auch unabhängig von Desktop-Umgebungen gibt) kann man den Stick anstecken und abziehen ohne sich Gedanken um mount/umount machen zu müssen und die Daten sind trotzdem sicher. Der Artikel hinkt in puncto Komfort und Datensicherheit leider dem Stand der Linux-Technik hinterher.
Bitte nimm das und auch die anderen Kommentare hier auf keinen Fall persönlich! Du machst seit vielen Jahren schon einen wirklich guten Job, der Respekt verdient!
Ein heutiger Flash Speicher kann die grosse Anzahl der Schreibvorgaenge die beim FAT Dateisystem im "Inhaltsverzeichnis" gemacht werden nicht verkraften. Man braucht in der Regel einen 1 GB grossen Stick nur 2 - 3 mal vollschreiben wenn "sync" an ist, und der Speicher ist hinueber.
Das gilt natuerlich nicht fuer Festplatten, die kann man "sync" mounten.
Dieses Verhalten von Flash Speicher ist uebrigens auch der Grund dafuer, dass es unter Windows das "sichere Aushaengen" von USB Speicher gibt, Microsoft koennte auch viel Nutzerfreundlicher sein und den Speicher synchron mounten.
Lasst euch das von jemandem sagen, der bereits 2 USB-Sticks auf diese Art verheizt hat. Ich habe aus meinen Fehlern gelernt, bitte tut das auch.
Das ist schön, danke für den Tipp.
Unter Kernel 2.4 klappte das mit Hotplug allerdings auch schon ohne Probleme, vor allen Dingen desktopunabhängig und sogar auf einem reinen Konsolensystem.
Jedenfalls unter Suse 9.0.
Der angeschlossene Stick war jedenfalls immer unter /media/sdax (z.B. /media/sda1) zu finden.
Irgendwie scheint es da zwischenzeitlich einen Rückschritt gegeben zu haben.
aptitude install ivman
und man hat das oben beschrieben Verhalten - egal ob 2.4 oder 2.6.
Mir ging es um das "desktopunabhängig" und dass ich Zugriff auf den USB-Stick habe, ohne an irgendeiner Konfigurationsdatei nacharbeiten zu müssen.
Genau das klappt bei Suse 9.0, Kernel 2.4 (2.4.21-303) mit Hotplug, Konsolensystem (init 3).
USB-Stick anstecken, es ertönt ein Signal.
Danach "mount sda1" eingeben und man kann auf der Konsole auf den Stick zugreifen.
Ich muß nicht noch extra einen ivman oder Ähnliches installieren. Suse 9.0 hält den Stick systemweit unter /media/sda1 (bzw. /media/sdax) mountbar bereit.
Die fstab ist dazu von Suse entsprechend automatisch geändert worden.
Warum das so klappt?
Ganz einfach: Der USB-Stick wird eingesteckt und hotplug kreiert einen temporären Eintrag für den Stick in der fstab.
KDE- oder Gnome-Installationen moderner Linuxe machen zunächst Probleme, wenn man danach einfach nur bis zur Konsole (init 3) durchstartet, d.h. KDE bzw. Gnome überhaupt nicht startet.
Es wird auf der Konsole angezeigt, dass der USB-Stick erkannt wurde, aber ich kann ihn zunächst nicht mounten. Erst wenn ich z.B. von Hand die fstab entsprechend ändere, dann klappt das wieder. Ein einfaches "mount ..." reicht zunächst nicht, unter /media z.B. ist kein entsprechender Eintrag zu finden.
Ich bin damit also in diesem Fall heutzutage meistens ein kleines Stückchen schlechter dran als noch unter Suses altem 2.4-Kernel, insofern ich rein nur auf der Konsole arbeite oder eine alternative, schlanke Desktopumgebung wie etwa Fvwm benutze.
Seit 2.6 gibt es HAL und DBUS in alles Distributionen. Da ist es doch nur von Vorteil Programme wie ivman zu nutzen, die diese offiziellen Technologien unterstützen.
Und wenn man doch eine fette Desktop-Umgebung startet, wird da nichts doppelt gemacht. KDE und Gnome reagieren auch nur auf HAL- und DBUS-Events.
http://ivman.sourceforge.net/
Ja, nur mit Userrechten. Rootrechte sind nicht erforderlich.
Falls eine Desktopumgebung vorhanden ist, die Icons auf der jeweiligen Oberfläche unterstützt (z.B. KDE 3.1), so erscheint nach dem Einstecken des Sticks ein Icon mit dem Namen "sda1". Man muß allerdings noch mounten, d.h. in diesem Fall einfach draufklicken. Wird der Stick abgezogen, verschwindet das Icon wieder.
> Ein einfaches "mount ..." reicht zunächst nicht, unter /media z.B. ist kein entsprechender Eintrag zu finden.
Naja, jetzt komm... /mnt existiert wohl auch auf Deinem System
ohne x-server und desctopumgebung, usbrein und automagisch gemountet fertig
Das einizge was ich noch nicht ganz gefixt bekommen habe, dass, falls ein Netzlaufwerk (per nfsv3) nicht verfügbar ist und der server down, dann dauert die reaktion etwas und solange blockiert leider jeder Dateimanager. Bei USB-Geräten liegt die Reaktion natürlich im millisekunden bereich und ist somit nicht merkbar.
Aber wie das mit dem Aushängen ist weiß ich aber auch nicht aber da ich die dafür nötigen Devices nur read-only mounte ist die gefahr nicht gegeben. ^^
was ich von diesem Artikel (...ist mir nicht bekannt... ,..Mir ist es egal... usw.) halten soll.
Trotzdem an dieser Stelle auch von mir einen riesen-Dank für all die gute Arbeit, uns Nerds mit all den News, Tipps und Comments zu versorgen, die manchmal wichtiger sind als das "täglich Brot". Gruß auch an demon, der dem natürlich in Nix nachsteht.
Jeder schießt mal nen Bock und heute warste einfach dran :).
hab das vor zig monaten mal gemacht, funzt einwandfrei und sogar mit festem mountpoint fuer den speicher, wenn man will
oder hab ich ein programm vergessen, welches da noch mitspielt?
Nein. Es reicht, in /etc/udev/rules.d/ in einer der Dateien den Stick / die Platte anzugeben.
Klar, ist natürlich nicht so bequem wie der gnome-volume-manager. Auf der anderen Seite hält sich die Zahl meiner USB-Sticks in Grenzen und so wird jedes Gerät automatisch an einem bekannten Speicherort eingehängt, so daß man da auch Skripte drüberlaufen lassen kann.
unter debian installier ich einfach hal und mit den abhägigkeiten kommt auch udev mit, aber kein gnome (oder änlicher) volumen-manager
Die udev-Regeln sind letztlich nicht als Konfigurationsdateien gedacht.
Deswegen werden sie auch von /etc nach /lib verschoben werden, um u.a. das zu unterstreichen.
Mal was anderes, wie kann ich denn unter KDE4 (dbus, udev) grafisch automounten, das klappt noch nicht glaube ich, oder?
Hab sonst kein KDE4 installiert.
bei kde3 ging es bei mir darüber...
/thorsten
Was noch zu erwähnen ist, dass sich mit Hilfe von usbmount auch kinderleicht Skripte bei einem mount/umount aufrufen lassen, welche praktische Variablen wie $UM_MOUNTPOINT, $UM_DEVICE, $UM_FILESYSTEM (und ein paar mehr) zur Verfügung stellen.
Zu den anderen Kommentaren:
Sync ist bei den Mountoptionen per standard aktiv und im Artikel wird lediglich auf die Warnung des Entwicklers in der Konfigurationsdatei eingegangen.
Btw. Das ganze eignet sich sehr gut um USB-Sticks zu kopieren...
-> Abziehen
USB-Stick ran -> Skript aufruf -> Wenn fertig ein `beep`
Besonders schön, wenn man mal eben keinen X-Server oder Tastatur zur Hand hat. (Zb. MediaCenterPC)
Grüße