Am Freitag, 27. Oktober 2006 00:18 schrieb David Haller: Hallo David,
Am Don, 26 Okt 2006, Al Bogner schrieb:
Am Sonntag, 22. Oktober 2006 21:46 schrieb David Haller:
Schau's dir an, awk ist einfacher:
awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts
| sh -x
Nun ja, in ein paar Monaten nicht mehr, wenn ich awk wieder brauche. Ich weis aber dann wo ich nachsehen kann ;-)
Das verwendet eigentlich nur awk Grundlagen, keinerlei Finessen. Der einzige "Trick" ist, dass per awk ein shellscript mit den passenden umount-Befehlen generiert wird, welches dann per pipe an sh verfuettert wird. Im Prinzip koennte man auch das noch in awk machen:
$1 ~ dev { system("umount "$1); }
wobei man da noch ne Fehlerbehandlung dazubauen sollte (Rueckgabewert von 'system')...
Hmmh, ich habe schon gemerkt, dass es ziemlich komplex werden kann, wenn man jeden möglichen Fehler abfangen will. Ich nehme daher zB an, dass nur 1 USB-Stick angeschlossen ist. Wenn jemand als root angemeldet ist, dann darf davon ausgegangen werden, dass nicht jeder Blödsinn gemacht wird. Wie meinst du das mit der Fehlerbehandlung? Wenn das Script nicht abgebrochen wird, wird sowieso alles gelöscht. Warum sollte ein umount nicht klappen, wenn es als root ausgeführt wird? Es ist auch nicht davon auszugehen, dass die Partition gerade von jemanden anders gemountet wurde. In diesem Zusammenhang habe ich noch folgende theoretische Frage, da ich davon ausgehe, dass auf dem Stick nur 1 primäre Partition vorhanden ist. Wie mounte ich alle vorhandenen Partitionen automatisch ähnlich den awk-umount-Konstrukt? Als Problem sehe ich die Zuordnung der mountpoints. Zur Zeit habe ich: MOUNTVERZEICHNIS="/mnt" awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x mount "$USBGERAET"1 "$MOUNTVERZEICHNIS" ls -la "$MOUNTVERZEICHNIS" Das reicht solange nur 1 primäre Partition verwendet wird. Ich stelle mir vor, dass ich vorsichtshalber alle Partitionen abmelde und dann dynamische Mountpoints generiere.
user/users Optionen in /etc/fstab. bzw. Rechte an den Devices selbst. Wie das mit udev etc. geht weiss ich aber nicht.
Mit udev hatte ich schon genug Ärger, dann lasse ich das mal mit Root-Rechten.
Es gibt noch ein Problem mit dem Mounten des Sticks nach Ausführen des Scripts. Vielleicht ist es aber ein KDE-Problem.
Auf einem anderen Rechner machte es keine Probleme.
Hast du Lust das Script per PM zu überfliegen?
Mal schauen. Schick's ruhig mal :)
Mache ich, nachdem noch ein paar Dinge dazu gekommen sind, speziell der Teil oben.
Ohne Kommentare sieht das Script gegen Ende etwa so aus: sfdisk "$USBGERAET" << EOF ,,b EOF
Bei nem Einzeiler wuerde ich
echo ",,b" | sfdisk "$USBGERAET"
vorziehen.
mkdosfs -v -F 32 -n "$STICKNAME" "$USBGERAET"1
^^^^^^^^^^^^^ "${USBGERAET}1"
Liest sich IMHO einfacher, ist aber mehr Geschmackssache.
mount "$USBGERAET"1 /mnt
Dito. Bei beiden fehlt aber ne Fehlerbehandlung.
Wie sollte die aussehen und warum?
cp -vr "$STICKBASIS"* /mnt
Das duerfte die Rechte versauen. Besser:
cp -av "${STICKBASIS}/*" /mnt/
Rechte mit FAT 32? Siehe oben Partitionstyp ist b.
oder
cd "${STICKBASIS}" && tar -cp -f - . | ( cd /mnt/ && tar xp -f - )
umount "$USBGERAET"1
s.o.
Beim Ab- und Anstecken des Scripts meckert dann KDE 3.5.5, dass kein "Mail versandt werden konnte, oder so ähnlich.
Wie wird das script aufgerufen? Da soll wohl eine Ausgabe per Mail versandt werden... Oder so ;)
Nein, kein Mail. Das Script wird aus einem Root-Terminal aufgerufen.
Ggfs. hilft ein (script-globales) Umleiten der Ausgaben per
exec 1>/bla.log exec 2>/bla.err
oder ein Klammer des scripts mit:
#!/bin/bash { script } | logger ....
oder sowas ;)
In dieser Richtung habe ich noch keine Überlegungen.
Da fällt mir gerade ein, ein "Verify" der kopierten Dateien mit star oder sha1sum-Vergleich könnte man noch daran hängen.
Jo. Lesevorgaenge verkuerzen AFAIR ja nicht die Lebensdauer von Flash-Medien ;)
Bei den Preisen denke ich nicht mehr an die Lebensdauer. Ich habe 3 Jahre Garantie und dann ist der Stick sowieso etwas fürs Museum, wie der 64MB Test-Stick. Ähnliches gilt für SD-Karten, aber so oft kommen die sowieso nicht in gefährdete Systeme. Al