HILFE:undo rm -r /etc aus versehen gelöscht auf Reiserfs !!!!
Hallo Zusammen, Ich möschte nicht von euch hören backup, Ich habe eins aber kein Actuelles hab habe wegen den Profile sehr viel in der /etc geandert und Sie leider durch eine kleine falsche Wiederholung gelöscht ... ;-(((( Gibt es da was zu machen sind ja nur 38 Mb ich habe vor dem Runterfahren noch eine image mit dd angefertig. Bitte um Hilfe ist sehr wichtig, Danke an euch alle. Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
Patrice Staudt, Freitag, 11. April 2003 12:28:
Ich möschte nicht von euch hören backup, Ich habe eins aber kein Actuelles hab habe wegen den Profile sehr viel in der /etc geandert und Sie leider durch eine kleine falsche Wiederholung gelöscht ... ;-((((
Gibt es da was zu machen sind ja nur 38 Mb ich habe vor dem Runterfahren noch eine image mit dd angefertig.
Bitte um Hilfe ist sehr wichtig,
Geht dauernd über die Liste. 1. Kein Schreibzugriff mehr auf die Partition. 2. reiserfsck --rebuild-tree probieren. Das Backup hast Du ja. Du kannst genauso Dein dd-Image mounten, und dort dann Deine reiserfsck-Versuche unternehmen. Dann aber leg vorher eine Kopie des Images an. Damit Du mehrere Versuche hast. -- Andreas Feile www.feile.net
Hallo Andreas,
1. Kein Schreibzugriff mehr auf die Partition.
Ich mußte sie ausmachen da ich keine Email Kontakt mehr hatte.
2. reiserfsck --rebuild-tree probieren.
Habe ich gemacht ohne erfolgt, die Diskution geht seit Januar durch die Liste wie ein Undelte gehen soll. Ist ein Anderes FS besser dafür vorbereitet?? Was kann ich noch versuchen?? Wenn ich es mit dem Update überschreibe dann komme ich auch nicht mehr an die Arbeit der 5 Letzte Tage!! ;-((( Er legt effectiv beim sck ein Directorie Lost+Found an wie es Ext2 Standart Mässig anlegt. Aber das rebuild kann doch kein undelete, oder was habe ich da falsch verstanden? Noch ein Idee Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
Patrice, bitte lasse die Attribution Line stehen, sonst weiss niemand mehr, wer was in diesem Thread gesagt hat (betrifft z.B. den Punkt 2. unten...) Patrice Staudt wrote:
2. reiserfsck --rebuild-tree probieren.
Habe ich gemacht ohne erfolgt, die Diskution geht seit Januar durch die Liste wie ein Undelte gehen soll. Ist ein Anderes FS besser dafür vorbereitet??
Prinzipiell ist unter Linux kein undelete vorgesehen. Wenn man eine Datei loescht, dann wird sie zwar nicht physikalisch ueberschrieben oder auf der Platte ge- loescht, sondern erst einmal nur ihr Eintrag aus dem "Inhaltsverzeichnis" genommen, aber trotzdem ist sie fuer den Anwender weg. Ist die Datei noch nicht phy- sikalisch auf der Platte ueberschrieben (um das zu verhindern, sollte die betroffene Partition sofort read-only gemountet werden), so kann man sie mit Auf- wand wieder herstellen, in dem sie praktisch wieder ins "Inhaltsverzeichnis" aufgenommen wird. Etwas in der Art kann ein "reiserfsck --rebuild-tree" wohl be- wirken (das kann auch genau das Gegenteil bewirken und der Schuss ginge somit nach hinten los; deswegen sollte man den Befehl eher auf ein per Loop-Device gemountetes Image loslassen und/oder alles auf der Partition backupen, was einem wichtig ist). Ebenso gibt es Methoden fuer ext2/ext3 - dazu findet man einiges im Internet und auch im Archiv der Liste. Trotz alledem sollte man immer davon ausgehen, dass ein "rm" Dateien unwiederbringlich loescht! Alles an- dere ist nur mit viel Glueck und Geschickt verbunden... Wenn Du /etc geloescht hast, dann kannst Du das nur als root gemacht haben. Als root ist stets doppelte Vorsicht geboten, insbesondere mit rekursivem Loeschen! Wenn das beschriebene Vorgehen bei reiserFS nicht hilft, dann solltest Du Dich langsam damit abfinden, dass /etc weg ist. Das klingt jetzt zynisch, aber sieh es als lehrreiches Ereignis. Man sollte nur als root arbeiten, wenn unbedingt noetig; man sollte als root stets doppelte und dreifache Vorsicht walten lassen; man sollte aktuelle Backups haben, insbesondere wenn man recht viel aendert am System. Vielleicht findest Du ja doch noch einen Weg, Dein System zu "retten", ich wuensche es Dir, aber dann hast Du wirklich sehr viel Glueck gehabt. Viele Gruesse, Th.
Thomas Hertweck wrote:
Prinzipiell ist unter Linux kein undelete vorgesehen.
Falsch: Prinzipiell ist ein undelete vorgesehen. Es gibt auch eine Implementierung. http://amadeus.uprm.edu/~undelete/ http://recover.sourceforge.net/links/ man chattr (Arribute 'u') Peter
Peter Wiersig wrote:
Thomas Hertweck wrote:
Prinzipiell ist unter Linux kein undelete vorgesehen.
Falsch: Prinzipiell ist ein undelete vorgesehen. Es gibt auch eine Implementierung.
Hmmm, ich lese auf der Seite
"The undelete inode in the ext2 filesystem is inode 6. It was reserved in the design of the ext2 filesystem but not implemented." Hmmm, ich finde auf
das ext2-undeletion-howto mit dem Text: "It is vital to remember that Linux is unlike MS-DOS when it comes to undeletion. For MS-DOS, it is generally fairly straightforward to undelete a file - the `operating system' (I use the term loosely) even comes with a utility which automates much of the process. For Linux, this is not the case. So, rule number one (the prime directive, if you will) is: KEEP BACKUPS no matter what. " Recover macht letztendlich auch nichts anderes, was an- sonsten immer von Hand gemacht wird und sich zahlreich im Archiv dieser Liste findet. Es ist also nichts Neues und kein wirkliches "undelete". Hmmm, ich lese in
man chattr (Arribute 'u')
(aktuelle Version 1.32) unter Bugs and Limitations: "As of Linux 2.2, the `c', 's', and `u' attribute are not honored by the kernel filesystem code. These attributes will be implemented in a future ext2 fs version. The `j' option is only useful if the filesystem is mounted as ext3. The `D' option is only useful on Linux kernel 2.5.19 and later." Mal davon abgesehen, dass es hier um ReiserFS geht. Irgendwie kann ich damit Deinen Ausfuehrungen nicht so ganz folgen. Ein "undelete" war vielleicht mal vorgesehen, aber bis zur Anwendbarkeit hat es das wohl nie geschafft. Viele Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hallo Peter,
Falsch: Prinzipiell ist ein undelete vorgesehen. Es gibt auch eine Implementierung.
http://amadeus.uprm.edu/~undelete/
http://recover.sourceforge.net/links/
man chattr (Arribute 'u')
Habe ich so nicht anwenden können sieht auch nach ext2 aus. Oder? Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
Patrice Staudt schrieb:
Falsch: Prinzipiell ist ein undelete vorgesehen. Es gibt auch eine Implementierung.
http://amadeus.uprm.edu/~undelete/
http://recover.sourceforge.net/links/
man chattr (Arribute 'u')
Habe ich so nicht anwenden können sieht auch nach ext2 aus. Oder?
Es ist a) fuer ext2 und b) (chattr Attribut u) nicht imple- mentiert. Gruesse, Th. PS: Schreibe bitte beim Zitieren eine Einleitung, sonst kann niemand mehr nachvollziehen, wer in diesem Thread was gesagt hat (z.B. "Vorname Nachname schrieb:") -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hallo Thomas, Ich habe den stand wieder , es war ein Kurze Nacht. Ich habe mir eine neues rm gebaut a la Win sind Sie Sicher. Und ein Cron lauf und Speichert alle Anderung alles Stunden auch vom Windows Netzt , ich habe dazu gelernt. Leider auf eine Art und weisse. ;-(
Patrice Staudt wrote:
2. reiserfsck --rebuild-tree probieren.
Hat reiserfsck überhaupt eine Möglichkeit zu restorieren von gelöschten Datensätzen.? Wie ich die Doku beurteile Nein. Auch der versuch über das loop hat nicht gebracht. Leider. Ich habe Teile auf XFS umgestellt weil da Quota unterstutzung vorhanden ist. Wie sind die Erfahrungen bei dir damit?
Trotz alledem sollte man immer davon ausgehen, dass ein "rm" Dateien unwiederbringlich loescht! Alles an- dere ist nur mit viel Glueck und Geschickt verbunden...
Ich hatte kein glück ich weiß ja zum Glück was ich gemacht habe durch die Doku. Aber es hätte so einfacht schon fertig seien können. >
Wenn das beschriebene Vorgehen bei reiserFS nicht hilft, dann solltest Du Dich langsam damit abfinden, dass /etc weg ist. Das klingt jetzt zynisch, aber sieh es als lehrreiches Ereignis. Man sollte nur als root arbeiten, wenn unbedingt noetig; man sollte als root stets doppelte und dreifache Vorsicht walten lassen;
Es gibst aber viele Sache die nicht anders zu machen sind, sudo .. Na ja.
man sollte aktuelle Backups haben, insbesondere wenn man recht viel aendert am System. Ich hatte vor einer Umstellung alle etc automatisch auf dem Server gesichert. Ist wieder da. .. Murfi Gesetzt.
Doch nicht so viel Glück gehabt. Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
On Sat, Apr 12, 2003 at 03:40:36PM +0200, Patrice Staudt wrote:
Hat reiserfsck überhaupt eine Möglichkeit zu restorieren von gelöschten Datensätzen?
Nein.
Ich habe Teile auf XFS umgestellt weil da Quota unterstutzung vorhanden ist. Wie sind die Erfahrungen bei dir damit?
Ich habe eine Partition auf XFS, und das Hauptsystem auf reiserfs. Die Maschine ist kris@valiant:~> uptime 5:21pm up 11 days, 22:00, 4 users, load average: 0.09, 0.10, 0.05 kris@valiant:~> cat /etc/SuSE-release SuSE Linux 8.0 (i386) VERSION = 8.0 kris@valiant:~> uname -a Linux valiant 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown Sie bleibt regelmäßig alle paar Wochen stehen mit einem Oops im XFS, insbesondere wenn heftige Aktivität auf dem XFS stattfindet. Daten sind bisher noch nie verloren gegangen. Dein Problem mit dem Undelete löst das auch nicht. Kristian
Patrice Staudt schrieb:
Hat reiserfsck überhaupt eine Möglichkeit zu restorieren von gelöschten Datensätzen.? Wie ich die Doku beurteile Nein.
Reiserfsck hat prinzipiell nicht die Aufgabe, Dateien wiederherzustellen. Es ist ein Tool zum Ueberpruefen und Reparieren des Filesystems. Wie hier in der Liste berichtet wurde, scheint allerdings ein "angenehmer" Nebeneffekt zu sein, dass damit unter Umstaenden ge- loeschte Dateien "wieder auftauchen". Man sollte aber nicht denken, dass Reiserfsck deswegen ein "undelete" darstellt. Es kann funktionieren, muss aber nicht, und unter Umstaenden macht man damit auch noch mehr kaputt.
Ich habe Teile auf XFS umgestellt weil da Quota unterstutzung vorhanden ist. Wie sind die Erfahrungen bei dir damit?
Ich habe hier einen Rechner mit Vanilla-Kernel 2.4.20 mit xfs Patch. Der Rechner laeuft 24/7 und es arbeiten (zumindest tagsueber, nachts laufen numerische Berech- nungen und Backups) im Schnitt 6 User darauf (kleiner Arbeitsgruppenserver). Fuer unsere Datenplatten, auf denen grosse seismische Datensaetze gespeichert sind und verarbeitet werden, benutzen wir xfs. Die Kiste ist bisher sehr stabil: 1:28pm up 122 days, 2:45, 6 users, load average: 0.06, 0.01, 0.00 Am Wochenende ist wenig los :-) Wir sind hier mit xfs bisher recht zufrieden, kennen es aber von unseren SGI Servern natuerlich schon lange. Nur, ganz prinzipiell, Du wirst auch mit xfs die gleichen Probleme haben wie Du nun mit ReiserFS gehabt hast... Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hallo zusammen, Ich habe mir eine Lössung gebaubt für die Zukunft. del als ersatzt für rm -r Ich werfe alles in ein Papeirkorb des users auch für root und ein Putzfrau macht den Papierkorb einmal im Monat lehr wenn das zeugt seit Einem Monat drin ist. Ich nutzte einfach eine Möglichkeit die ich mir unter Samba geschafen habt um geloschte Server Platten das gelöchte auf zufangen. Ich muß mir nur angewohne del anstatt von rm zu nutzen. #!/bin/bash # Shell del echo "Loeschen in Papierkorb $1 wird in ~/Papierkorb/$1 Verschoben" mv $1 ~/Papierkorb/$1 # ende in die /bin/del wie kann ich zuvor überpruefen ob der User die Aktion durchführen darf? Hatte ich das gehabt und genutzt wäre ich besser gefahren. Sollte man sich angewohnen. Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
* Patrice Staudt schrieb am 13.Apr.2003:
Ich habe mir eine Lössung gebaubt für die Zukunft. del als ersatzt für rm -r Ich werfe alles in ein Papeirkorb des users auch für root und ein Putzfrau macht den Papierkorb einmal im Monat lehr wenn das zeugt seit Einem Monat drin ist. Ich nutzte einfach eine Möglichkeit die ich mir unter Samba geschafen habt um geloschte Server Platten das gelöchte auf zufangen. Ich muß mir nur angewohne del anstatt von rm zu nutzen.
#!/bin/bash # Shell del echo "Loeschen in Papierkorb $1 wird in ~/Papierkorb/$1 Verschoben" mv $1 ~/Papierkorb/$1 # ende
in die /bin/del
wie kann ich zuvor überpruefen ob der User die Aktion durchführen darf? Hatte ich das gehabt und genutzt wäre ich besser gefahren. Sollte man sich angewohnen.
<imhomode> Viel Sinnvoller ist es, sich anzugewöhnen, genau nachzudenken, wenn man rm benutzt. </imhomode> Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
On Son, 13 Apr 2003 at 15:25 (+0200), Bernd Brodesser wrote:
* Patrice Staudt schrieb am 13.Apr.2003:
Ich habe mir eine Lössung gebaubt für die Zukunft. del als ersatzt für rm -r Ich werfe alles in ein Papeirkorb des users auch für root und ein Putzfrau macht den Papierkorb einmal im Monat lehr wenn das zeugt seit Einem Monat drin ist. Ich nutzte einfach eine Möglichkeit die ich mir unter Samba geschafen habt um geloschte Server Platten das gelöchte auf zufangen. Ich muß mir nur angewohne del anstatt von rm zu nutzen.
#!/bin/bash # Shell del echo "Loeschen in Papierkorb $1 wird in ~/Papierkorb/$1 Verschoben" mv $1 ~/Papierkorb/$1 # ende
in die /bin/del
wie kann ich zuvor überpruefen ob der User die Aktion durchführen darf? Hatte ich das gehabt und genutzt wäre ich besser gefahren. Sollte man sich angewohnen.
<imhomode>
Viel Sinnvoller ist es, sich anzugewöhnen, genau nachzudenken, wenn man rm benutzt.
</imhomode>
ACK. Zum Script: Patrice, hast Du das schon mal für Dateien mit Leerzeichen oder anderen Sonderzeichen im Namen versucht? jan@k500:~/tmp/del> ll insgesamt 4 -rw-r--r-- 1 jan users 0 Apr 13 18:46 * -rw-r--r-- 1 jan users 0 Apr 13 18:46 Datei mit Leerzeichen -rwxr-xr-x 1 jan users 115 Apr 13 18:48 del jan@k500:~/tmp/del> ./del * Loeschen in Papierkorb * wird in ~/Papierkorb/* Verschoben mv: Beim Verschieben mehrerer Dateien muß das letzte Argument ein Verzeichnis sein Versuchen Sie »mv --help« für weitere Informationen. jan@k500:~/tmp/del> ./del \* Loeschen in Papierkorb * wird in ~/Papierkorb/* Verschoben mv: Beim Verschieben mehrerer Dateien muß das letzte Argument ein Verzeichnis sein Versuchen Sie »mv --help« für weitere Informationen. jan@k500:~/tmp/del> ./del Datei\ mit\ Leerzeichen Loeschen in Papierkorb Datei mit Leerzeichen wird in ~/Papierkorb/Datei mit Leerzeichen Verschoben mv: Beim Verschieben mehrerer Dateien muß das letzte Argument ein Verzeichnis sein Versuchen Sie »mv --help« für weitere Informationen. _Dieses_ Script würde ich nicht auf die Menschheit loslassen. Jan
Moin, Am Son, 2003-04-13 um 18.49 schrieb Jan Trippler:
On Son, 13 Apr 2003 at 15:25 (+0200), Bernd Brodesser wrote:
<imhomode>
Viel Sinnvoller ist es, sich anzugewöhnen, genau nachzudenken, wenn man rm benutzt.
</imhomode>
ACK.
Tja. Wie oft haben fünf Leute nachgeadacht, was falsches produziert, und das ist hinterher von sechs Kontrolleuren übersehen worden? So gesehen... :-)
_Dieses_ Script würde ich nicht auf die Menschheit loslassen.
Tip: Ich habe sowas schonmal bei freshmeat.org gesehen, "aber ordentlich". Da würd ich mal wühlen, bevor mehr kaputtgeht als repariert wird. Von Sternchen und Anführungsstrichen im Dateinamen mal ganz abgesehen... Gruß, Ratti -- fontlinge Font management for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
Hallo Joerg, Du hast leider recht. Aber wenn ich so etwas gehabt hätte währe, alles nicht so schlimm gewesen. Ich bin nur spontan auf so eine Lössung gekommen. Es fehlte auch das erzeugen von Papierkorb ..
Tip: Ich habe sowas schonmal bei freshmeat.org gesehen, "aber ordentlich". Da würd ich mal wühlen, bevor mehr kaputtgeht als repariert wird. Von Sternchen und Anführungsstrichen im Dateinamen mal ganz abgesehen...
Wo kann ich es finden ?? Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
Moin, Am Mon, 2003-04-14 um 17.55 schrieb Patrice Staudt:
Du hast leider recht. Aber wenn ich so etwas gehabt hätte währe, alles nicht so schlimm gewesen.
"Wenn das Wörtchen 'wenn' nicht wär' , wär' die Platte jetzt nicht leer." Ups. 'schuldigung. :-)
Tip: Ich habe sowas schonmal bei freshmeat.org gesehen, "aber ordentlich". Da würd ich mal wühlen, bevor mehr kaputtgeht als repariert wird. Von Sternchen und Anführungsstrichen im Dateinamen mal ganz abgesehen...
Wo kann ich es finden ??
Sorry, falls du lange gesucht hast. www.freshmeat.NET, nicht .ORG. Wie gesagt, nicht selbst getestet, nur gesehen: http://freshmeat.net/projects/trashcan/ #-- Trash Can is a command line recycle bin for Linux/*NIX-based systems. ksh, bash, or zsh is needed. It can remove files/directories and restore them in their original path, delete single files from the trash can, automatically delete 'core' and 'dead.letter' files, automatically purge the trash over X days old, empty the trash, and display the disk usage and stored files. It is compressed to take up less room and warns you in varying degrees as your trash can fills up. It will prompt the user if restoring over an existing file. Dynamic multiple user installation/uninstallation scripts are included. #-- Gruß, Ratti -- fontlinge Font management for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
Am Sonntag, 13. April 2003 18:49 schrieb Jan Trippler:
On Son, 13 Apr 2003 at 15:25 (+0200), Bernd Brodesser wrote:
* Patrice Staudt schrieb am 13.Apr.2003:
Ich habe mir eine Lössung gebaubt für die Zukunft. del als ersatzt für rm -r Ich werfe alles in ein Papeirkorb des users auch für root und ein Putzfrau macht den Papierkorb einmal im Monat lehr wenn das zeugt seit Einem Monat drin ist. Ich nutzte einfach eine Möglichkeit die ich mir unter Samba geschafen habt um geloschte Server Platten das gelöchte auf zufangen. Ich muß mir nur angewohne del anstatt von rm zu nutzen.
#!/bin/bash # Shell del echo "Loeschen in Papierkorb $1 wird in ~/Papierkorb/$1 Verschoben" mv $1 ~/Papierkorb/$1 # ende
[...]
Zum Script: Patrice, hast Du das schon mal für Dateien mit Leerzeichen oder anderen Sonderzeichen im Namen versucht?
jan@k500:~/tmp/del> ll insgesamt 4 -rw-r--r-- 1 jan users 0 Apr 13 18:46 * -rw-r--r-- 1 jan users 0 Apr 13 18:46 Datei mit Leerzeichen -rwxr-xr-x 1 jan users 115 Apr 13 18:48 del
Na ja, solche Dateien sollte es auf einem *nix-Systen doch eigentlich nicht geben? Oder?
jan@k500:~/tmp/del> ./del * Loeschen in Papierkorb * wird in ~/Papierkorb/* Verschoben mv: Beim Verschieben mehrerer Dateien muß das letzte Argument ein Verzeichnis sein Versuchen Sie »mv --help« für weitere Informationen. jan@k500:~/tmp/del> ./del \* Loeschen in Papierkorb * wird in ~/Papierkorb/* Verschoben mv: Beim Verschieben mehrerer Dateien muß das letzte Argument ein Verzeichnis sein Versuchen Sie »mv --help« für weitere Informationen. jan@k500:~/tmp/del> ./del Datei\ mit\ Leerzeichen Loeschen in Papierkorb Datei mit Leerzeichen wird in ~/Papierkorb/Datei mit Leerzeichen Verschoben mv: Beim Verschieben mehrerer Dateien muß das letzte Argument ein Verzeichnis sein Versuchen Sie »mv --help« für weitere Informationen.
_Dieses_ Script würde ich nicht auf die Menschheit loslassen.
Das Problem mit den mehrfachen Dateien kann doch gelöst werden: #!/bin/bash # srm (secure remove) for i in $* do echo "./$i wird nach $HOME/Papierkorb/ verschoben" mv ./$i $HOME/Papierkorb/ done #!/bin/bash # urm (un-remove) A=$HOME/Papierkorb/$1 for i in $A do echo "$i wird nach ./ verschoben" mv $i ./ done Ist zwar nicht perfekt - aber für normale Dateien reicht es. lg, Andreas
Moin, Am Mon, 2003-04-14 um 22.11 schrieb Andreas Scherer:
Am Sonntag, 13. April 2003 18:49 schrieb Jan Trippler:
jan@k500:~/tmp/del> ll insgesamt 4 -rw-r--r-- 1 jan users 0 Apr 13 18:46 * -rw-r--r-- 1 jan users 0 Apr 13 18:46 Datei mit Leerzeichen -rwxr-xr-x 1 jan users 115 Apr 13 18:48 del
Na ja, solche Dateien sollte es auf einem *nix-Systen doch eigentlich nicht geben? Oder?
[ ] Du hast auf deinem *x-System Samba, AppleTalk und nfsd und alle arbeiten klaglos miteinander [x] User scheissen drauf, was du ihnen sagst :-) Ich berichte immer wieder gerne, von einer Datei, die eine Grafikerin bei uns angelegt hat mit dem schönen Namen: * Schlauchschelle 3 1/4" Ja, kann man toppen. Lang aber. :-) Gruß, Ratti -- fontlinge Font management for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
Hallo, On Mon, 14 Apr 2003, Andreas Scherer wrote: [..]
#!/bin/bash # srm (secure remove) for i in $* ^^ *patsch*
Mach das mal, wenn Leerzeichen vorkommen -- und das ist nicht grad selten. for f in "$@"
do echo "./$i wird nach $HOME/Papierkorb/ verschoben" mv ./$i $HOME/Papierkorb/ ^^^^ *patsch*2
Auch hier quotest du nicht. Und wer sagt, dass nur Dateien im lokalen Verzeichnis geloescht werden sollen? mv -i "$f" "${HOME}/Papierkorb" Weitere Kritik erspare ich mir...
Ist zwar nicht perfekt - aber für normale Dateien reicht es.
Dann definierst du "normale" Dateinamen aber sehr eng. -dnh PS: Ich glaub fast, "wir" muessen mal ein tar.gz mit Test-Dateien online stellen... -- I'd play with your mind, but I prefer bigger toys. -- Tyger
Hallo David, Danke für deine Kritik ich hätte viel wenig Ärger gehabt Wenn das noch etwas gemacht werden sollte : #!/bin/bash # srm (secure remove) trash=$HOME/Papierkorb; if ! test -x $trash ; then mkdir $trash; echo "Neuer Ordner $trash"; fi for file in "$@" do mv -i "$file" "$trash/$$-$1"; if [ $? -eq 0 ] ; then echo "$file wird nach $trash/$$-$1 verschoben"; else echo "Es könnte nicht geloscht werden !!"; fi done Mit der $$ kann ich erreichen wen mehr mals gelöscht wird es nicht überschrieben wird. Wäre da noch was sinnvolles zu machen ? Danke für Kontruktive vorschläge. Ist es nicht sinnvoll ?? :-) Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
On Die, 15 Apr 2003 at 09:57 (+0200), Patrice Staudt wrote:
Hallo David,
Der bin ich zwar nicht ...
Danke für deine Kritik ich hätte viel wenig Ärger gehabt Wenn das noch etwas gemacht werden sollte :
#!/bin/bash # srm (secure remove) trash=$HOME/Papierkorb; if ! test -x $trash ; then mkdir $trash; echo "Neuer Ordner $trash"; fi
Nicht gut: Du testest, ob es eine Datei $trash gibt, die das x-Bit gesetzt hat - nicht, ob es ein Verzeichnis ist. Du musst den Returncode des mkdir abfangen, z. B. so: test -d $trash || mkdir $trash || exit 1
for file in "$@" do mv -i "$file" "$trash/$$-$1"; if [ $? -eq 0 ] ; then echo "$file wird nach $trash/$$-$1 verschoben"; else echo "Es könnte nicht geloscht werden !!"; fi done
Die ; am Zeilenende sind überflüssig. Das ist nicht C.
Mit der $$ kann ich erreichen wen mehr mals gelöscht wird es nicht überschrieben wird. Wäre da noch was sinnvolles zu machen ?
Was passiert in Deinem Script, wenn z. B. als Argument dir1/datei1 angegeben wird? Genau: mv will nach $trash/$$-dir1/datei1 verschieben und bricht dabei zusammen. Dein Fall ($$) berücksichtigt ebenfalls nicht, dass es z. B. dir1/datei1, dir2/datei1, dir3/datei1 geben kann. mv -i verhindert zwar das Überschreiben, der Anwender hat dann aber die Wahl, entweder nicht zu löschen oder zu überschreiben. Beide Varianten sind nicht sonderlich erstrebenswert (vor allem, wenn viele Dateien mit dem gleichen Namen auftauchen - denke nur mal an eine Webseite mit lauter index.html-Dateien). Ich würde folgenden Ansatz angehen (ungetestet): cnt=1 for file in "$@" do new="$trash/`basename \"$1\"`-$$.$cnt" mv "$file" "$new" if [ $? -eq 0 ] ; then echo "$file wurde nach $new verschoben" else echo "Es konnte nicht gelöscht werden!" fi cnt=`expr $cnt + 1` done Jan
On Die, 15 Apr 2003 at 21:09 (+0200), Jan Trippler wrote: [...] Ups, da habe ich doch glatt einen fiesen Fehler von Dir übernommen, Patrice :-)
Ich würde folgenden Ansatz angehen (ungetestet):
cnt=1 for file in "$@" ^^^^ da drin steht der aktuelle Dateiname. do new="$trash/`basename \"$1\"`-$$.$cnt" ^^ und deshalb ist das hier Quatsch! So muss es heißen: new="$trash/`basename \"$file\"`-$$.$cnt"
mv "$file" "$new" if [ $? -eq 0 ] ; then echo "$file wurde nach $new verschoben" else echo "Es konnte nicht gelöscht werden!" fi cnt=`expr $cnt + 1` done
Bei der Gelegenheit habe ich gleich noch mal nachgedacht: Es kann ja immer noch sein, dass zufällig eine Datei gleichen Namens in trash existiert. Außerdem haben wir noch das Problem, dass der Anwender u. U. Verzeichnisse angibt. Deshalb ist folgender Ansatz besser: cnt=1 for file in "$@" do if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue fi new="$trash/`basename \"$file\"`" while test -f "$new"; do cnt=`expr $cnt + 1` new="$trash/`basename \"$file\"`-$$.$cnt" done mv "$file" "$new" if [ $? -eq 0 ] ; then echo "$file wurde nach $new verschoben" else echo "Es konnte nicht gelöscht werden!" fi done Jetzt kann höchstens noch die while-Schleife bis zum MAXINT laufen und dann das Script abbrechen, aber wenn dieser Fall eintritt, läuft eh was schief ;-) Und zu guter Letzt noch was: Dieser Mülleimer nutzt Dir wenig, wenn Du Dir nicht merkst, wie die Originalpfade der Dateien hießen (dann wird nämlich das Wiederherstellen ein ziemliches Rätselraten). Als schnelle Hilfe könntest Du eine Textdatei in trash hinterlegen, die den Originalpfad speichert: Folgende Zeile direkt nach dem mkdir ausführen (das verhindert, dass der Anwender vielleicht gerade eine Datei .filelist löscht und damit unsere Liste sabotiert ;-): test -f $trash/.filelist || touch $trash/.filelist und nach dem mv: ... if [ $? -eq 0 ] ; then echo "$file wurde nach $new verschoben" echo "`pwd`: $file -> $new" >>$trash/.filelist else echo "Es konnte nicht gelöscht werden!" fi ... Das pwd zum Anfang hat den Sinn, bei relativen Pfaden zu wissen, wo das aktuelle Verzeichnis war. Die Ausgabe in die Dateiliste kann man natürlich beliebig verfeinern ;-) Eine andere Alternative: Alle verschobenen Dateien werden mit ihrem Pfad verschoben (dann kann man das auch für Verzeichnisse erlauben - vorausgesetzt, sie liegen im gleichen Dateisystem): cnt=1 for file in "$@" do if test -d "$file"; then newfn= newdn="$file" else newfn="`basename \"$file\"`" newdn="`dirname \"$file\"`" fi newdn="$trash`(cd \"$newdn\"; pwd)`" while test -f "$newdn/$newfn"; do cnt=`expr $cnt + 1` newfn="$trash/`basename \"$file\"`-$$.$cnt" done mkdir -p "$newdn" && mv "$file" "$newdn/$newfn" if [ $? -eq 0 ] ; then echo "$file wurde nach $new verschoben" else echo "Es konnte nicht gelöscht werden!" fi done Warum nun dieser Aufwand zum Erzeugen von $newdn? Damit kriegt man - egal wie das Ausgangsargument aussieht - einen sauberen absoluten Pfadnamen hin: jan@k500:~> mkdir tmp/dir\ mit\ leer jan@k500:~> x=../jan/tmp/dir\ mit\ leer/abc jan@k500:~> newdn="`(cd \"\`dirname \\\"$x\\\"\`\"; pwd)`" jan@k500:~> echo $newdn /home/jan/tmp/dir mit leer Alles dies ist nicht komplett durchgetestet - also gut nachgucken! Jan
Hallo, On Tue, 15 Apr 2003, Jan Trippler wrote:
On Die, 15 Apr 2003 at 21:09 (+0200), Jan Trippler wrote:
Ich würde folgenden Ansatz angehen (ungetestet):
cnt=1 for file in "$@" ^^^^ da drin steht der aktuelle Dateiname. do new="$trash/`basename \"$1\"`-$$.$cnt" ^^ und deshalb ist das hier Quatsch! So muss es heißen: new="$trash/`basename \"$file\"`-$$.$cnt"
Apropos, u.a. an Patrice, so werden Variablen mit Dateinamen richtig gequotet ;) [..]
Bei der Gelegenheit habe ich gleich noch mal nachgedacht: Es kann ja immer noch sein, dass zufällig eine Datei gleichen Namens in trash existiert. Außerdem haben wir noch das Problem, dass der Anwender u. U. Verzeichnisse angibt. Deshalb ist folgender Ansatz besser:
cnt=1 for file in "$@" do if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue
¿Por qué? base="`basename \"$file\"`" if test -d "$file" then new="${trash}/${base}" while test -d "$new" do test $cnt -le 9999 || { echo "Fehler:...">&2; exit 1; } cnt=$((cnt+1)) new="${trash}/${base}-$$.$cnt" done
fi new="$trash/`basename \"$file\"`" while test -f "$new"; do cnt=`expr $cnt + 1` new="$trash/`basename \"$file\"`-$$.$cnt" done else while test -f "$new" do test $cnt -le 9999 || { echo "Fehler:...">&2; exit 1; } cnt=$((cnt+1)) new="${trash}/${base}-$$.$cnt" done fi
mv "$file" "$new" if [ $? -eq 0 ] ; then echo "$file wurde nach $new verschoben" else echo "Es konnte nicht gelöscht werden!" fi done
if mv -i "$file" "$new" ## ich will immer noch auf der sicheren Seite ## sein, falls es zu einer Namenskollision kommt then echo "$file wurde nach $new verschoben" else echo "Kann $file nicht in den Papierkorb verschieben" fi Ich hasse diese hirnrissige: befehl if befehl_der_prueft_ob_befehl_ok; then ... Entweder, ein Befehl gibt einen sinnvollen Exit-status zurueck, den muss man dann nicht auch noch mit 'test' ueberpruefen, um dann den Exit-status von 'test' auszuwerten. Das erinnert mich immer an "Von hinten durch die Brust ins Auge"... Oder, ein Befehl gibt keinen auswertbaren Exit-status zurueck, dann muss man den so oder so auswerten (da hilft dann auch $? genau gar nichts, da steht dann eh nur der nicht sinnvolle Exit-status drin), z.B. durch ein '|grep -q blubb' hintendran. Und das ergibt dann immer noch folgende Konstruktion: if befehl | grep -q blubb; then ... Fazit: $? ist in allen Faellen ueberfluessig, in denen man den Exit-status _nicht_ explizit einer benamsten Variablen zuweist oder z.B. mittels echo ausgibt. Folgendes illustriert diese beiten Ausnahmen, in denen $? sinnvoll ist: ==== befehl befehl_status="$?" case $befehl_status in 1) ...;; 2) ...;; *) ...;; esac exit $befehl_status ==== ==== ziemlich sinnfrei ==== error() { echo "$1 wurde mit Fehler beendet: exitcode: $2" >&2 } fatal() { error "$@" exit $2 } befehl || error "befehl" $? nochnbefehl || fatal "nochnbefehl" $? ====
Jetzt kann höchstens noch die while-Schleife bis zum MAXINT laufen und dann das Script abbrechen, aber wenn dieser Fall eintritt, läuft eh was schief ;-)
Ajup. s.o.
Und zu guter Letzt noch was: Dieser Mülleimer nutzt Dir wenig, wenn Du Dir nicht merkst, wie die Originalpfade der Dateien hießen (dann wird nämlich das Wiederherstellen ein ziemliches Rätselraten). Als schnelle Hilfe könntest Du eine Textdatei in trash hinterlegen, die den Originalpfad speichert:
[..]
Eine andere Alternative: Alle verschobenen Dateien werden mit ihrem Pfad verschoben (dann kann man das auch für Verzeichnisse erlauben - vorausgesetzt, sie liegen im gleichen Dateisystem):
cnt=1 for file in "$@" do if test -d "$file"; then newfn= newdn="$file" else newfn="`basename \"$file\"`" newdn="`dirname \"$file\"`" fi newdn="$trash`(cd \"$newdn\"; pwd)`"
*huch*[tm]. Da fehlt noch die Fehlerbehandlung, falls das cd fehlschlaegt... Und wozu die subshell? newdn="${trash}/`cd \"$newdn\" || exit -1; pwd -P`" ==== ~ (0)$ cd /opt/kde /opt/kde (0)$ x=bin/kcmjoy /opt/kde (0)$ f="`basename \"$x\"`" /opt/kde (0)$ d="`dirname \"$x\"`" /opt/kde (0)$ echo "$d $f" bin kcmjoy /opt/kde (0)$ n="/TRASH/`cd \"$d\" || exit -1; pwd -P`" /opt/kde (0)$ echo "$n" /TRASH//usr/local/opt/kde/bin /opt/kde (0)$ d="blubb" /opt/kde (0)$ n="/TRASH/`cd \"$d\" || exit -1; pwd -P`" bash: cd: blubb: No such file or directory /opt/kde (255)$ ==== Wie man sieht, werde ich weder ausgeloggt, und der exit-status (im prompt in den '()') ist ebenfalls korrekt ;)
while test -f "$newdn/$newfn"; do cnt=`expr $cnt + 1`
Was hast du eigentlich gegen $(( ))? Ja, $[] ist ein "bashism", aber $(( )) ist portabel "ueber" POSIX-shells. Allerdings nicht in bourne-shells. Aber die ash (die der bourne wohl recht nahe ist), kann auch das expr nicht, ist also egal ;) Die pdksh kann dagegen $(( )) und 'expr' aber nicht $[]. Oder gibt's ne (POSIX-)shell, die das expr kann, aber nicht das $(( ))? Ah, die tcsh kann expr, aber nicht $(( )), allerdings scheitert man da sowieso an den Variablenzuweisungen. Apropos shells: ich verwende das Teil auch viel zu selten, aber... ==== perlsh /home/dh: $ $x=1 perlsh /home/dh: $ $x=$x+2 perlsh /home/dh: $ echo $x 3 perlsh /home/dh: $ echo $x ** 2 9 perlsh /home/dh: $ cd "/opt/kde" perlsh /usr/local/opt/kde: $ use Cwd qw(abs_path) perlsh /usr/local/opt/kde: $ $x="bin/kcmjoy" perlsh /usr/local/opt/kde: $ echo abs_path($x) /usr/local/opt/kde/bin/kcmjoy ==== *bg* So Sachen wie das 'use Cwd qw(abs_path)' usw. kann man natuerlich in die config ("preload") aufnehmen, dann geht das ;) Allerdings ist die perlsh (ich hab' hier aber noch die vom 27.1.00) in Teilen noch recht unfertig und "alpha" oder so, und ob die noch ueberhaupt noch weiterentwickelt wird weiss ich auch nicht. Fuer Perlianer ist perlsh aber ein nettes Spielzeug statt 'perl -e' ;)
Warum nun dieser Aufwand zum Erzeugen von $newdn? Damit kriegt man - egal wie das Ausgangsargument aussieht - einen sauberen absoluten Pfadnamen hin: jan@k500:~> mkdir tmp/dir\ mit\ leer jan@k500:~> x=../jan/tmp/dir\ mit\ leer/abc jan@k500:~> newdn="`(cd \"\`dirname \\\"$x\\\"\`\"; pwd)`" jan@k500:~> echo $newdn /home/jan/tmp/dir mit leer
*g* -dnh PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen? -- WANTED: Schroedingers Cat, dead or alive.
* David Haller schrieb am 16.Apr.2003:
On Tue, 15 Apr 2003, Jan Trippler wrote:
cnt=1 for file in "$@" do if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue
Und was ist mit Symlinks, Gerätedateien, Named Pipes und Sockets?
Ich hasse diese hirnrissige:
befehl if befehl_der_prueft_ob_befehl_ok; then ...
Entweder, ein Befehl gibt einen sinnvollen Exit-status zurueck, den muss man dann nicht auch noch mit 'test' ueberpruefen, um dann den Exit-status von 'test' auszuwerten.
ACK!
Folgendes illustriert diese beiten Ausnahmen, in denen $? sinnvoll ist:
Ich habe den $? in meinem Prompt eingebaut, halte ich auch für eine recht Sinnvolle Sache. So weiß ich immer, ob etwas geklappt hat oder nicht. Auch noch wenn ich zwischendurch blödsinnigerweise date oder ls oder sowas gesagt habe.
Was hast du eigentlich gegen $(( ))? Ja, $[] ist ein "bashism", aber $(( )) ist portabel "ueber" POSIX-shells. Allerdings nicht in bourne-shells. Aber die ash (die der bourne wohl recht nahe ist), kann auch das expr nicht, ist also egal ;) Die pdksh kann dagegen $(( )) und 'expr' aber nicht $[]. Oder gibt's ne (POSIX-)shell, die das expr kann, aber nicht das $(( ))? Ah, die tcsh kann expr, aber nicht $(( )), allerdings scheitert man da sowieso an den Variablenzuweisungen.
Was ist den mit $( )? Halte ich für schöner als ` ` ist aber nicht prtabel auf bourne-shells. Wie sieht es mit anderen shells aus?
Apropos shells: ich verwende das Teil auch viel zu selten, aber...
Guck einer an. perlsh kannte ich noch gar nicht, werde ich mir sicherlich mal ansehen müssen.
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
;) Bitte Kontrollzeichen im Namen nicht vergessen. *fg* Ich muß gestehen, daß ich mir Euer Skript nicht so genau angesehen habe, und hier in der Mail ist es ja reichlich zerstückelt. Aber habt Ihr auch bedacht, daß eine Datei auch ein Hardlink haben kann? Im gleichen Verzeichnis oder in einem anderen? Wird wahrscheinlich auch nur in $trash verschoben. Ist das so gewollt? Ich glaube, die ganze Verschieberrei wirft weit mehr Probleme auf, als es löst. Vor allem verläßt man sich darauf und wird schludrig bei der Verwendung von rm. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Hallo, On Wed, 16 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
On Tue, 15 Apr 2003, Jan Trippler wrote:
cnt=1 for file in "$@" do if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue
Und was ist mit Symlinks, Gerätedateien, Named Pipes und Sockets?
*mirdochegal* *eg*
Folgendes illustriert diese beiten Ausnahmen, in denen $? sinnvoll ist:
Ich habe den $? in meinem Prompt eingebaut, halte ich auch für eine recht Sinnvolle Sache. So weiß ich immer, ob etwas geklappt hat oder nicht. Auch noch wenn ich zwischendurch blödsinnigerweise date oder ls oder sowas gesagt habe.
Habe ich auch so. Und das Terminal hab ich auch drin: TTY="`tty`" export TTY="${TTY##*[\/a-zA-Z]}" PS1='\[\033[1;37;44m\]\u@\h[ \[\010${TTY}\]]:\[\033[0m\] \w ( \[\010$?\])\$\[\033[0m\] ' case $TERM in xterm*) PS1="\[\033]0;\u@\h[${TTY}]: \w\007\]${PS1}";; esac export PS1 Das muckt aber bei langen Pfaden noch...
Was hast du eigentlich gegen $(( ))? [..]
Was ist den mit $( )? Halte ich für schöner als ` ` ist aber nicht prtabel auf bourne-shells. Wie sieht es mit anderen shells aus?
$() verwende ich eigentlich selten, da eben ein bashism... Und wenn ich mehr als einfach verschachteln muss, dann loese ich das eben ueber eine Variable auf, das ist dann eh besser lesbar.
Apropos shells: ich verwende das Teil auch viel zu selten, aber...
Guck einer an. perlsh kannte ich noch gar nicht, werde ich mir sicherlich mal ansehen müssen.
Wie gesagt, hat einige Macken und tut nur zum Teil, ist aber nett zum rumspielen ;)
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
;) Bitte Kontrollzeichen im Namen nicht vergessen. *fg*
Sowieso nicht. Backspace, Newline, Anfuehrungszeichen usw. muss mit rein. Halt alles ausser \0 und / ;) [..]
Ich glaube, die ganze Verschieberrei wirft weit mehr Probleme auf, als es löst. Vor allem verläßt man sich darauf und wird schludrig bei der Verwendung von rm.
Ack. -dnh -- AIX looks like one space alien discovered Unix, and described it to another different space alien who then implemented AIX. But their universal translators were broken and they'd had to gesture a lot. --Mike Andrews
* David Haller schrieb am 16.Apr.2003:
On Wed, 16 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
;) Bitte Kontrollzeichen im Namen nicht vergessen. *fg*
Sowieso nicht. Backspace, Newline, Anfuehrungszeichen usw. muss mit rein. Halt alles ausser \0 und / ;)
Was passiert eigentlich, wenn im Dateiname ein / auftaucht? Das / könnte man im Dateinamen bekommen, wenn man hart auf die Device schreibt. vi /dev/hda1 Ihh, bin ich fies! Achso: Bitte liebe Kinder, nicht nachmachen, könnte die ganze Partition zerstören. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Hallo, On Thu, 17 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
On Wed, 16 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
;) Bitte Kontrollzeichen im Namen nicht vergessen. *fg*
Sowieso nicht. Backspace, Newline, Anfuehrungszeichen usw. muss mit rein. Halt alles ausser \0 und / ;)
Was passiert eigentlich, wenn im Dateiname ein / auftaucht?
Ich vermute mal, der Kernel (genauer, das (V)FS-Modul) wird sich weigern, einen solchen Dateinamen anzulegen... Teste z.B. mal mit ner (v)fat-Partition und ner perl-Manpage (die einen ':' enthaelt)... Da bekommst du nur ein "Nee, duu, so'n Dateinamen wollma net, hamma net, kringwa auch nich mer rein, also lassense uns in Ruh mit all son Zeuch" ;)
Das / könnte man im Dateinamen bekommen, wenn man hart auf die Device schreibt. vi /dev/hda1
Ouhauerha! *snigger* Aber bei sowas zieh ich vche dem vi und dem (x)emacs vor.
Ihh, bin ich fies!
Ja, auf die Weise kannst du latuernich jedes FS korrumpieren. Und wo ich schonmal dabei bin sabotier ich auch gleich noch den BS oder die FAT ;) Am besten so, dass sich das FS vom vfat-code unter Linux noch lesen und schreiben, bzw. schlicht "normal" verwenden laesst, aber Win* beim Zugriff abstuerzt (hehe) (AFAIR koennte das sogar gehen, nen rekursiver offset oder so... *eg*) Ich denke aber, wir sollten uns schon auf Dateinamen beschraenken, die sich auf legal via Kernel-VFS anlegen lassen... Achso, wenn wir so nen tarball haben, dann sollte es ggfs. vom VFS-code passende Fehlermeldungen geben, wenn man den tarball versucht auszupacken...
Achso: Bitte liebe Kinder, nicht nachmachen, könnte die ganze Partition zerstören.
Oh ja! Auch von mir nochmal die Warnung: DO NOT DO ANY OF THIS AT HOME! NOR AT WORK! Ich (und ich denke, auch gleich im Namen von Bernd und Jan) bzw. wir lehnen JEDE Folge JEGLICHER ART, die durch die evtl. Verwendung des o.g. oder des evtl. Tarballs mit solchen Dateinamen oder durch sonst etwas, was wir hier schreiben ab. Soweit es uns angeht schreiben wir hier staendig von 'rm -rf /' als root. Und wer das ausfuehrt und ist a) doof, und b) selber schuld und hat keinerlei Mitleid verdient. *harharharhar* -dn'*SCNR*'h, kann uns da vielleicht ein juristisch vorgebildeter einen besseren Disclaimer entwerfen? ;) PS: der vfat-code ist b0rken. Der legt u.U. defekte DOS-Namen an. Ich bin leider noch nicht dazu gekommen, das mit dem anderen charset-Parameter zu ueberpruefen... -- F: Was sagt ein frisch Assimilierter zu seinem Ex-Captain? A: SCNR [Bernd Reinecke]
Hallo David, hallo Bernd, hallo Leute, Am Donnerstag, 17. April 2003 03:49 schrieb David Haller:
On Thu, 17 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
On Wed, 16 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
BTW: Gute Idee ;-)
;) Bitte Kontrollzeichen im Namen nicht vergessen. *fg*
Sowieso nicht. Backspace, Newline, Anfuehrungszeichen usw. muss mit rein. Halt alles ausser \0 und / ;)
Was passiert eigentlich, wenn im Dateiname ein / auftaucht? [...] Das / könnte man im Dateinamen bekommen, wenn man hart auf die Device schreibt. vi /dev/hda1
Ouhauerha! *snigger*
Und gerade weil das so heimtückisch ist, probier ich es gleich mal aus (keine Angst, nur in einer "ext2-Datei" ;-) also nicht auf einer echten Partition.)
Ihh, bin ich fies!
Ja, auf die Weise kannst du latuernich jedes FS korrumpieren.
Klar, aber es ist (immerhin ;-) keine Katastrophe (und mit einem Hex-Editor wieder rückgängig zu machen) ### DISCLAIMER: Bitte NICHT NACHMACHEN! Für Folgen jeglicher Art ### übernehme ich keine Haftung! Legen wir also los: cb@tux:~> cd /tmp cb@tux:/tmp> dd if=/dev/zero of=./testfs bs=1M count=1 1+0 Records ein 1+0 Records aus cb@tux:/tmp> /sbin/mkfs.ext2 testfs # [...] cb@tux:/tmp> su Password: root@tux:/tmp> mount -o loop testfs /mnt/ root@tux:/tmp> cd /mnt/ root@tux/mnt> touch das_ist_ein_testfile root@tux:/mnt> ls -l -rw-r--r-- 1 root root 0 2003-04-18 22:41 das_ist_ein_testfile drwx------ 2 root root 12288 2003-04-18 22:40 lost+found root@tux:/mnt> cd - root@tux:/tmp> umount /mnt root@tux:/tmp> exit cb@tux:/tmp> cp testfs testfs_buggy cb@tux:/tmp> khexedit testfs_buggy # "das_ist_ein_testfile" in "das_ist/ein_testfile" geändert cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy e2fsck 1.28 (31-Aug-2002) testfs_buggy: clean, 12/128 files, 34/1024 blocks # !!! ^^^^^ !!! cb@tux:/tmp/tmp-cb/test> su Password: root@tux:/tmp> mount -o loop testfs_buggy /mnt/ root@tux:/tmp> cd /mnt/ root@tux:/tmp> ls -al ls: /mnt/das_ist_ein/testfile: Datei oder Verzeichnis nicht gefunden insgesamt 17 drwxr-xr-x 3 cb users 1024 2003-04-18 22:41 . drwxr-xr-x 27 root root 4096 2003-04-18 21:59 .. drwx------ 2 root root 12288 2003-04-18 22:40 lost+found # wegen des Fehlers enthält der folgende Prompt den Exitcode [1] #(keine Fußnote ;-) [1] root@tux:/tmp/tmp-cb/test> ls -al /mnt/lost+found/ insgesamt 13 drwx------ 2 root root 12288 2003-04-18 22:40 . drwxr-xr-x 3 cb users 1024 2003-04-18 22:41 .. Also nix in lost+found, dafür aber eine Fehlermeldung von ls, nämlich ls: das_ist/ein_testfile: Datei oder Verzeichnis nicht gefunden Das bringt mich aber auf eine Idee ;-) cb@tux:/mnt> mkdir das_ist cb@tux:/mnt> touch das_ist/ein_testfile # legt eine Datei im Verzeichnis das_ist an cb@tux:/mnt> ls -al insgesamt 18 drwxr-xr-x 4 cb users 1024 2003-04-18 23:02 ./ drwxr-xr-x 27 root root 4096 2003-04-18 21:59 ../ drwxr-xr-x 2 cb users 1024 2003-04-18 23:02 das_ist/ -rw-r--r-- 1 cb users 0 2003-04-18 23:02 das_ist/ein_testfile drwx------ 2 root root 12288 2003-04-18 22:40 lost+found/ cb@tux:/mnt> echo Hallo > das_ist<tab><tab> das_ist ein_testfile # Huch[tm] Wieso wird mir da "ein_testfile" angeboten? # Auch find sieht die Datei mit gefälschtem Namen: cb@tux:/mnt> find . ./lost+found ./das_ist/ein_testfile ./das_ist ./das_ist/ein_testfile cb@tux:/tmp> rm das_ist/ein_testfile # Datei "ein_testfile" im Verzeichnis "das_ist" löschen cb@tux:/mnt> find . ./lost+found find: ./das_ist/ein_testfile: Datei oder Verzeichnis nicht gefunden ./das_ist So, genug getestet. Deshalb: root@tux:/tmp> umount /mnt ; exit Übrigens: während der ganzen Aktion ist keine Fehlermeldung in /var/log/messages gelandet, fsck.ext2 beklagt sich auch nicht (!) Mit dem Hexeditor lässt sich die Namensänderung wieder rückgängig machen.
Ich denke aber, wir sollten uns schon auf Dateinamen beschraenken, die sich auf legal via Kernel-VFS anlegen lassen...
Ooch, das ist ja langweilig *g*
Achso: Bitte liebe Kinder, nicht nachmachen, könnte die ganze Partition zerstören.
Oh ja! Auch von mir nochmal die Warnung:
DO NOT DO ANY OF THIS AT HOME! NOR AT WORK!
Da schließe ich mich gleich an! Bitte NICHT NACHMACHEN! (egal wo ;-) Auch für das von mir geschriebene gilt:
Ich (und ich denke, auch gleich im Namen von Bernd und Jan) bzw. wir lehnen JEDE Folge JEGLICHER ART, die durch die evtl. Verwendung des o.g. oder des evtl. Tarballs mit solchen Dateinamen oder durch sonst etwas, was wir hier schreiben ab.
Gruß Christian Boltz -- Registrierter Linux-Nutzer #239431 Linux - life is too short for reboots.
On Fre, 18 Apr 2003 at 23:58 (+0200), Christian Boltz wrote: [...]
Und gerade weil das so heimtückisch ist, probier ich es gleich mal aus (keine Angst, nur in einer "ext2-Datei" ;-) also nicht auf einer echten Partition.) [Hex-Editor-Experimente]
Das Experiment beweist IMHO nur eines: Der Slash ist kein zulässiges Zeichen in einem Dateinamen. Das hätte ich Dir aber auch so sagen können ;-) Ein mit einem Hex-Editor unbrauchbar gemachtes FS ist kein Ort, in dem artige Shell-Scripts sich aufhalten sollten. Man könnte am ehesten noch dem fsck einen Vorwurf machen, aber ich habe keine Möglichkeit gesehen, dass fsck die Verzeichniseinträge auf ungültige Dateinamen prüfen soll (habe allerdings auch nicht lange gesucht). Jan
Christian Boltz wrote:
root@tux:/tmp> umount /mnt (...) cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy e2fsck 1.28 (31-Aug-2002) testfs_buggy: clean, 12/128 files, 34/1024 blocks # !!! ^^^^^ !!!
Klar, du hast es ja zuvor sauber ausgehangen. ein "e2fsck -f" waere interessanter.
fsck.ext2 beklagt sich auch nicht (!)
Mit, oder ohne -f? Peter
Hallo Peter, hallo Leute, Am Sonntag, 20. April 2003 02:00 schrieb Peter Wiersig:
Christian Boltz wrote:
root@tux:/tmp> umount /mnt (...) cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy e2fsck 1.28 (31-Aug-2002) testfs_buggy: clean, 12/128 files, 34/1024 blocks # !!! ^^^^^ !!!
Klar, du hast es ja zuvor sauber ausgehangen.
ein "e2fsck -f" waere interessanter.
Guter Tip ;-)
fsck.ext2 beklagt sich auch nicht (!)
Mit, oder ohne -f?
Meine Versuche habe ich ohne -f durchgeführt. Jetzt aber mal mit -f: cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy -f e2fsck 1.28 (31-Aug-2002) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Entry 'very_bad/file_name' in / (2) has illegal characters in its name. Fix<y>? yes Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information testfs_buggy: ***** FILE SYSTEM WAS MODIFIED ***** testfs_buggy: 12/128 files (0.0% non-contiguous), 34/1024 blocks [1] cb@tux:/tmp> ^^^ Ist der Exitcode von fsck.ext2 und keine Fußnote ;-) Danach findet sich die Datei wieder mit einem gültigen Namen (der "/" wurde durch einen Punkt ersetzt) im Verzeichnis. Frohe Ostern! Christian Boltz -- [Festplatte im Wechselrahmen] Oder meinst du, da du mehrere Platten hast, die sich nicht im Gehäuse in die Quere kommen, springen keine Pinguine auf die Windowsplatte und zertrümmern die Fenster mit ih- ren Watschelbeinchen. [Thorsten von Plotho-Kettner in suse-linux]
Hallo, On Sun, 20 Apr 2003, Christian Boltz wrote:
cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy -f
*patsch* Christian, bitte, Optionen _vor_ Argumenten! Was du daheim im stillen Kaemmerlein machst sei dir ueberlassen, aber wenn du hier (oder anderswo) schreibst, dann unterlasse bitte diese, aehm, hoeflich gesagt, Unsitte.
e2fsck 1.28 (31-Aug-2002) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Entry 'very_bad/file_name' in / (2) has illegal characters in its name. Fix<y>? yes [..] Danach findet sich die Datei wieder mit einem gültigen Namen (der "/" wurde durch einen Punkt ersetzt) im Verzeichnis.
*hehe* e2fsck gefaellt mir :) -dnh -- dagegen wirkt SuSEFirewall gesund wie ein frisch geficktes eichhoernchen. -- f. paulsen, dasr
Hallo David, hallo Leute, Am Dienstag, 6. Mai 2003 23:36 schrieb David Haller:
On Sun, 20 Apr 2003, Christian Boltz wrote:
cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy -f
*patsch*
*autsch*
Christian, bitte, Optionen _vor_ Argumenten! Was du daheim im stillen Kaemmerlein machst sei dir ueberlassen, aber wenn du hier (oder anderswo) schreibst, dann unterlasse bitte diese, aehm, hoeflich gesagt, Unsitte.
Mach ich ja üblicherweise[TM] ;-) In diesem Fall war es IIRC so, dass ich einfach <Cursor up> <space> -f <return> getippt habe, da kommt man eben zu solchen Befehlszeilen ;-)
e2fsck 1.28 (31-Aug-2002) Entry 'very_bad/file_name' in / (2) has illegal characters in its name. Fix<y>? yes
Danach findet sich die Datei wieder mit einem gültigen Namen (der "/" wurde durch einen Punkt ersetzt) im Verzeichnis.
*hehe* e2fsck gefaellt mir :)
Es wäre mal interessant, den gleichen Test mit z. B. reiserfs zu machen ;-) (einige Zeit später) Den Mitschnitt der Konsole spare ich mir jetzt mal, nur soviel: ich habe - ähnlich wie bei meinen Versuchen mit ext3 - in einer Datei (40 MB, wesentlich kleiner mag Reiserfs nicht...) ein reiserfs-Dateisystem angelegt, loopback gemounted, darin eine Datei angelegt (mit touch), umount ausgeführt und danach mit dem Hexeditor den Dateinamen (der übrigens zweimal zu finden war) geändert, und zwar an beiden Fundstellen einen "/" in den Namen eingebaut. Ergebnis von fsck.reiserfs war, dass es nur mit --rebuild-tree die Möglichkeit gäbe, die Datei wiederherzustellen. Im Detail: cb@tux:/tmp/tmp-cb/test> /sbin/reiserfsck testfs_buggy reiserfsck 3.6.4 (2002 www.namesys.com) [...] Checking internal tree..bad_directory_item: block 8211: The directory item [1 2 0x1 DIR (3)] has a not properly hashed entry (2) bad_leaf: block 8211, item 1: The corrupted item found (1 2 0x1 DIR (3), len 88, location 3964 entry count 3, fsck need 0, format old) finished Comparing bitmaps..finished Fatal corruptions were found, Semantic pass skipped 1 found corruptions can be fixed only during --rebuild-tree ########### reiserfsck finished at Thu May 8 00:27:10 2003 ########### Nach dem --rebuild-tree lag die Datei dann mit einem völlig falschem Namen ("2_3" statt "das_ist_eine_testdatei") im lost+found des reiserfs :-| - da gefällt mir ext2 doch wesentlich besser ;-) Auch heute wieder der Disclaimer: Bitte NICHT NACHMACHEN, insbesondere nicht auf "echten" Partitionen. Für einen evtl. Datenverlust durch obige Experimente und/oder Reperaturversuchen übernehme ich keine Haftung! Gruß Christian Boltz -- _Du_ unterstellst _mir_, daß ich meinen Rechner mit Windows quäle? Das solltest du doch besser wissen. Ich brauche keine MS- Produkte, um meinen Rechner zu quälen. [Florian Gross zu David Haller in suse-linux]
Hallo, On Thu, 08 May 2003, Christian Boltz wrote:
Am Dienstag, 6. Mai 2003 23:36 schrieb David Haller:
On Sun, 20 Apr 2003, Christian Boltz wrote:
cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy -f
*patsch*
*autsch*
*Eisbeutel-reich*
Christian, bitte, Optionen _vor_ Argumenten! Was du daheim im stillen Kaemmerlein machst sei dir ueberlassen, aber wenn du hier (oder anderswo) schreibst, dann unterlasse bitte diese, aehm, hoeflich gesagt, Unsitte.
Mach ich ja üblicherweise[TM] ;-) In diesem Fall war es IIRC so, dass ich einfach <Cursor up> <space> -f <return> getippt habe, da kommt man eben zu solchen Befehlszeilen ;-)
Ja. Mach ich (aber nur selten!) so -- aber irgendwo in ne Mail oder nen script schreib ich sowas nicht! Es gibt eben haufenweise Anwendungen, die _nicht_ getopt verwenden, und dann schiesst du dir mit so einer Verwendung boes ins Knie. Ich hab mir stattdessen einfach "<up><C-a><A-f><space>" angewoehnt... (wobei aber die C- A- Kombinationen von mir eher als je 1 Tastendruck wahrgenommen werden).
e2fsck 1.28 (31-Aug-2002) Entry 'very_bad/file_name' in / (2) has illegal characters in its name. Fix<y>? yes
Danach findet sich die Datei wieder mit einem gültigen Namen (der "/" wurde durch einen Punkt ersetzt) im Verzeichnis.
*hehe* e2fsck gefaellt mir :)
Es wäre mal interessant, den gleichen Test mit z. B. reiserfs zu machen ;-)
(einige Zeit später)
Den Mitschnitt der Konsole spare ich mir jetzt mal, nur soviel: ich habe - ähnlich wie bei meinen Versuchen mit ext3 - in einer Datei (40 MB, wesentlich kleiner mag Reiserfs nicht...)
Ja, das ist FS-spezifisch, reiserfs belegt immer IIRC ca. 35 MB fuer's Journal und/oder die Hashtabelle. ext2/3 hat da den Vorteil, dass die Inode Anzahl (und der davon verbrauchte Platz) mit dem FS waechst, aber bei einem kleinen FS auch nur wenig Platz braucht. Das hatten wir neulich auch in Bezug auf ne initrd...
ein reiserfs-Dateisystem angelegt, loopback gemounted, darin eine Datei angelegt (mit touch), umount ausgeführt und danach mit dem Hexeditor den Dateinamen (der übrigens zweimal zu finden war) geändert, und zwar an beiden Fundstellen einen "/" in den Namen eingebaut.
Ergebnis von fsck.reiserfs war, dass es nur mit --rebuild-tree die Möglichkeit gäbe, die Datei wiederherzustellen. Im Detail:
cb@tux:/tmp/tmp-cb/test> /sbin/reiserfsck testfs_buggy reiserfsck 3.6.4 (2002 www.namesys.com) [...] Checking internal tree..bad_directory_item: block 8211: The directory item [1 2 0x1 DIR (3)] has a not properly hashed entry (2) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^! bad_leaf: block 8211, item 1: The corrupted item found (1 2 0x1 DIR (3), len 88, location 3964 entry count 3, fsck need 0, format old) [..]
Nach dem --rebuild-tree lag die Datei dann mit einem völlig falschem Namen ("2_3" statt "das_ist_eine_testdatei") im lost+found des reiserfs :-|
Ist aber logisch, wenn man weiss, wie reiserfs "funzt" ;) ext2/3 speichert die Dateinamen ja in einer simplen Tabelle[1] in einer Datei (eben dem Verzeichnis). Reiserfs hingegen verwendet eine Hashtabelle, genauer eine BTree-Struktur die durch Hash-Werte der Dateinamen indiziert ist, oder so aehnlich[2]. Aenderst du nun also den Dateinamen, so aendert sich der Hash-Wert und der bisherige Eintrag ist Makulatur und es gibt keine Zuordnung mehr... Bei ext2/3 hingegen kannst du die Namen in den Verzeichnissen beliebig manipulieren, solange der Name seine Laenge nicht aendert muss man nichtmal die Eintraege fuer die Laenge anpassen ;) ext2/3 ist also wesentlich robuster in der Beziehung. Nochwas: Die Eintraege in den Verzeichnissen werden beim Loeschen nicht direkt angefasst, wenn man z.B. ausversehen eine Datei geloescht hat, dann kann man im Verzeichnis nach dem Inode (den man ja zum dump eh braucht) suchen und so auch wieder den Namen ;)
- da gefällt mir ext2 doch wesentlich besser ;-)
Mir auch, wobei, bis auf / und /home sind alle meine 11 Partitionen des Systems ext3. Und so langsam vertraue ich ext3 soweit, dass ich auch /home wohl noch umstelle :-)
Auch heute wieder der Disclaimer: Bitte NICHT NACHMACHEN, insbesondere nicht auf "echten" Partitionen. Für einen evtl. Datenverlust durch obige Experimente und/oder Reperaturversuchen übernehme ich keine Haftung!
ACK! -dnh, gib deinem sigmonster nen Keks mit Empfehlung von mir, ja? [1] genauer gesagt gibt es 2 Varianten, die aber beide einfach "kontinuierlich" in die Verzeichnisdatei geschrieben werden, siehe 'struct ext2_dir_entry' und 'struct ext2_dir_entry_2' in /usr/src/linux/include/linux/ext2_fs.h bzw. 'struct ext3_dir_entry' und 'struct ext3_dir_entry_2' in /usr/src/linux/include/linux/ext2_fs.h. [2] Vereinfacht gesagt, genaueres findet sich auf www.namesys.com und natuerlich in den reiserfs-Quellen. -- "Ach was! Wir reden doch eh genug, das du schon so langsam wissen müsstest wie und mit was Ich antworte. Vieleicht habe Ich in letzter Zeit einfach zu viele Froschpillen gegessen, das Ich so viel quacke?" [Woko° in dag°]
* David Haller schrieb am 08.Mai.2003:
On Thu, 08 May 2003, Christian Boltz wrote:
[/sbin/fsck.ext2 testfs_buggy -f]
Ja. Mach ich (aber nur selten!) so -- aber irgendwo in ne Mail oder nen script schreib ich sowas nicht! Es gibt eben haufenweise Anwendungen, die _nicht_ getopt verwenden, und dann schiesst du dir mit so einer Verwendung boes ins Knie.
Und es gibt eine Menge UNIXe neben GNU, wo sowas nicht funktioniert, auch nicht mit getopt.
Ich hab mir stattdessen einfach "<up><C-a><A-f><space>" angewoehnt... (wobei aber die C- A- Kombinationen von mir eher als je 1 Tastendruck wahrgenommen werden).
C-a hat screen schon im Beschlag
Ja, das ist FS-spezifisch, reiserfs belegt immer IIRC ca. 35 MB fuer's Journal und/oder die Hashtabelle. ext2/3 hat da den Vorteil, dass die Inode Anzahl (und der davon verbrauchte Platz) mit dem FS waechst, aber bei einem kleinen FS auch nur wenig Platz braucht. Das hatten wir neulich auch in Bezug auf ne initrd...
Und ext2/3 hat den Nachteil, daß man schon von vorneherein sagen muß, wieviele I-Nodes man haben möchte. Es kann einem passieren, daß man zwar noch viel Platz auf der Partiton hat, aber einem die I-Nodes ausgegangen sind. Sehr unschön, vor allem, weil man an sowas nicht denkt und erst mal einen Tag Fehlersuche verbratet um den Fehler zu finden. ;)
Ist aber logisch, wenn man weiss, wie reiserfs "funzt" ;) ext2/3 speichert die Dateinamen ja in einer simplen Tabelle[1] in einer Datei (eben dem Verzeichnis). Reiserfs hingegen verwendet eine Hashtabelle, genauer eine BTree-Struktur die durch Hash-Werte der Dateinamen indiziert ist, oder so aehnlich[2].
Hast Du mal was, wo die ReiserFS-Strucktur genauer erklärt wird. Möglichst in deuheutsch? Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Hallo, On Thu, 08 May 2003, Bernd Brodesser wrote:
* David Haller schrieb am 08.Mai.2003:
On Thu, 08 May 2003, Christian Boltz wrote:
[/sbin/fsck.ext2 testfs_buggy -f]
Ja. Mach ich (aber nur selten!) so -- aber irgendwo in ne Mail oder nen script schreib ich sowas nicht! Es gibt eben haufenweise Anwendungen, die _nicht_ getopt verwenden, und dann schiesst du dir mit so einer Verwendung boes ins Knie.
Und es gibt eine Menge UNIXe neben GNU, wo sowas nicht funktioniert, auch nicht mit getopt.
Ebent. Generell klappt das nur bei Anwendungen die GNU getopt verwenden, und das sind v.a. GNU shell-tools.
Ich hab mir stattdessen einfach "<up><C-a><A-f><space>" angewoehnt... (wobei aber die C- A- Kombinationen von mir eher als je 1 Tastendruck wahrgenommen werden).
C-a hat screen schon im Beschlag
Fehler von screen. C-a ist, wie auch die anderen emacs-editing Kuerzel readline default (siehe 'man 3 readline'). Commands for Moving beginning-of-line (C-a) Move to the start of the current line. Diese Dinge funktionieren (meist und groesstenteils) uebrigens auch mit vielen anderen Shells und Programmen.
Ja, das ist FS-spezifisch, reiserfs belegt immer IIRC ca. 35 MB fuer's Journal und/oder die Hashtabelle. ext2/3 hat da den Vorteil, dass die Inode Anzahl (und der davon verbrauchte Platz) mit dem FS waechst, aber bei einem kleinen FS auch nur wenig Platz braucht. Das hatten wir neulich auch in Bezug auf ne initrd...
Und ext2/3 hat den Nachteil, daß man schon von vorneherein sagen muß, wieviele I-Nodes man haben möchte. Es kann einem passieren, daß man zwar noch viel Platz auf der Partiton hat, aber einem die I-Nodes ausgegangen sind. Sehr unschön, vor allem, weil man an sowas nicht denkt und erst mal einen Tag Fehlersuche verbratet um den Fehler zu finden. ;)
Finde ich ein eher akademisches Problem. Inodes kann man leicht genug vorhalten, der Platzverbrauch ist marginal. Mir sind die Inodes noch nie auch nur knapp geworden (max. 30% verwendete Inodes auf einer vollen Partition). Schau dir mal 'df -i' an...
Ist aber logisch, wenn man weiss, wie reiserfs "funzt" ;) ext2/3 speichert die Dateinamen ja in einer simplen Tabelle[1] in einer Datei (eben dem Verzeichnis). Reiserfs hingegen verwendet eine Hashtabelle, genauer eine BTree-Struktur die durch Hash-Werte der Dateinamen indiziert ist, oder so aehnlich[2].
Hast Du mal was, wo die ReiserFS-Strucktur genauer erklärt wird.
www.namesys.com und die Quellen.
Möglichst in deuheutsch?
Da kenn ich nix. -dnh -- [about the "M$ Jet Engine"] But it's a very appropriate name, in that a jet engine is something that both sucks and blows. -- Paul Tomblin ... and if stuff gets inside, it either gets utterly mashed or causes the engine to disintegrate. -- Rik Steenwinkel
* David Haller schrieb am 08.Mai.2003:
On Thu, 08 May 2003, Bernd Brodesser wrote:
C-a hat screen schon im Beschlag
Fehler von screen. C-a ist, wie auch die anderen emacs-editing Kuerzel readline default (siehe 'man 3 readline').
Commands for Moving beginning-of-line (C-a) Move to the start of the current line.
Diese Dinge funktionieren (meist und groesstenteils) uebrigens auch mit vielen anderen Shells und Programmen.
Schön, mag ja sein, aber irgendwas muß screen als Kennung haben. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Hallo, On Fri, 09 May 2003, Bernd Brodesser wrote:
* David Haller schrieb am 08.Mai.2003:
On Thu, 08 May 2003, Bernd Brodesser wrote:
C-a hat screen schon im Beschlag
Fehler von screen. C-a ist, wie auch die anderen emacs-editing Kuerzel readline default (siehe 'man 3 readline').
Commands for Moving beginning-of-line (C-a) Move to the start of the current line.
Diese Dinge funktionieren (meist und groesstenteils) uebrigens auch mit vielen anderen Shells und Programmen.
Schön, mag ja sein, aber irgendwas muß screen als Kennung haben.
Ja. Aber C-a ist wirklich etwas ungeschickt, da einer der "Basis" Editierbefehle im emacs-Modus (und den vi-Modus will man auf der Kommandozeile ja selbst als vitischist nicht)... screen haette z.B. A-a nehmen koennen, das ist per default nicht belegt. Und auch die Belegung von M-a ('backward-sentence' in emacs, 'do-uppercase-version' in readline) ist obskur genug, dass screen die gerne haette verwenden koennen... Welche C- Kombinationen noch frei oder unwichtig genug waeren bin ich jetzt zu faul zum nachschauen... -dnh -- Wer Digitalkamera-Fotos unbehandelt ins Netz stellt gehoert standrechtlich mit Digitalkameras gesteinigt... -- K. B. Pruenner in dasr
* David Haller schrieb am 09.Mai.2003:
On Fri, 09 May 2003, Bernd Brodesser wrote:
[C-a]
Schön, mag ja sein, aber irgendwas muß screen als Kennung haben.
Ja. Aber C-a ist wirklich etwas ungeschickt, da einer der "Basis" Editierbefehle im emacs-Modus (und den vi-Modus will man auf der Kommandozeile ja selbst als vitischist nicht)...
Das behauptest Du immer wieder. Warum eigentlich? Ich werde mich das mal reintuen müssen. An der Kommandozeile benutze ich nicht besonders viel, nur die Cursortasten Page up und down, Backspace natürlich und wenn es hoch kommt noch Home und End. Das war es aber auch schon. TAB natürlich auch.
screen haette z.B. A-a nehmen koennen,
Nein, hätte es nicht. screen reagiert nicht auf Tastendrücke, sondern auf ASCII-Zeichen. Eine häufige Anwendung von screen ist z.B die remoteanwendung. Welches ASCII-Symbol gibt denn A-a ab. Ich schätze mal, daß es besser ist, wenn es wirklich ASCII ist und nicht einen Code über 128. Das der Code unter 32 sein sollte, versteht sich wohl von selst. Da bleibt somit nicht viel übrig.
das ist per default nicht belegt.
Warum nimmt emacs nicht was, was nicht von screen belegt ist?
Und auch die Belegung von M-a ('backward-sentence' in emacs, 'do-uppercase-version' in readline) ist obskur genug, dass screen die gerne haette verwenden koennen...
Welche C- Kombinationen noch frei oder unwichtig genug waeren bin ich jetzt zu faul zum nachschauen...
Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Hallo Bernd, hallo David, hallo Leute, Am Samstag, 10. Mai 2003 14:08 schrieb Bernd Brodesser:
* David Haller schrieb am 09.Mai.2003:
On Fri, 09 May 2003, Bernd Brodesser wrote:
Schön, mag ja sein, aber irgendwas muß screen als Kennung haben.
Ja. Aber C-a ist wirklich etwas ungeschickt, da einer der "Basis" Editierbefehle im emacs-Modus (und den vi-Modus will man auf der Kommandozeile ja selbst als vitischist nicht)...
Das behauptest Du immer wieder. Warum eigentlich?
Wüsste ich auch gern ;-) Ich habs seit heute Abend drin und komme ganz gut damit klar ;-)
Ich werde mich das mal reintuen müssen.
set -o vi - Sehr zu empfehlen ;-) Nach jedem ausgeführtem Kommando (also nach (fast) jedem Druck der Eingabetaste) landet man automatisch wieder im Einfügemodus. Zur Bewegung des Cursors kann man die vi-üblichen ESC irgendwas-Kombinationen verwenden, sogar das zurückholen des letzten Befehls mit ESC k geht :-)
das ist per default nicht belegt.
Warum nimmt emacs nicht was, was nicht von screen belegt ist?
ACK! *duck und nix wie weg* Nächtlicher Gruß Christian Boltz -- The nice thing about Windows is - It does not just crash, it displays a dialog box and lets you press 'OK' first.
Hallo, On Sat, 10 May 2003, Bernd Brodesser wrote:
* David Haller schrieb am 09.Mai.2003:
On Fri, 09 May 2003, Bernd Brodesser wrote: [C-a]
Schön, mag ja sein, aber irgendwas muß screen als Kennung haben.
Ja. Aber C-a ist wirklich etwas ungeschickt, da einer der "Basis" Editierbefehle im emacs-Modus (und den vi-Modus will man auf der Kommandozeile ja selbst als vitischist nicht)...
Das behauptest Du immer wieder. Warum eigentlich?
Weil's grauslich ist. Ja, ich hab's mal getestet.
Ich werde mich das mal reintuen müssen.
set -o vi
An der Kommandozeile benutze ich nicht besonders viel, nur die Cursortasten Page up und down, Backspace natürlich und wenn es hoch kommt noch Home und End. Das war es aber auch schon. TAB natürlich auch.
Ich verwende da schon deutlich mehr, z.B. C-left (M-b, A-b), C-right (M-f, A-f), C-a statt "Home" (Pos1), C-e statt "End", C-w bzw. A-Backspace, C-k, C-u, A-d, A-l, A-u, sowie natuerlich Controlcodes wie C-v, C-s, C-q, C-d, C-c... Achso, C-j, C-m usw. funktionieren auch...
screen haette z.B. A-a nehmen koennen,
Nein, hätte es nicht. screen reagiert nicht auf Tastendrücke, sondern auf ASCII-Zeichen. Eine häufige Anwendung von screen ist z.B die remoteanwendung. Welches ASCII-Symbol gibt denn A-a ab.
ESC a also "^[a" (siehe die Ausgabe von C-v A-a).
das ist per default nicht belegt.
Warum nimmt emacs nicht was, was nicht von screen belegt ist?
Weil emacs und libreadline und deren Eingabekonventionen ein klein wenig aelter als screen sind? Ja, screen ist immerhin von '87[1]... Emacs allerding spaetestens von '85... Achso, ich habe screen nichtmal installiert. Ich brauch das einfach nicht, mir reichen die Konsolen mit gpm[2] und normalerweise verwende ich eh X + WindowMaker als xterm-Multiplexer und fuer ein paar XEmacs-Fenster, siehe nicht-Zufallssig ;) -dnh [1] ja, ich bin ueberrascht, dass screen scheinbar so alt ist ;) [2] wer mit C-z, bg, fg usw. umzugehen weiss... Ok, fuer remote Sachen wo man sonst nohup bemuehen muss... Aber dafuer nehm ich dann ggfs. z.B. ein scripterl das dann im bg laeuft, aber ich arbeite eh eher selten remote... -- 9: GUI Ein Hintergrundbild und 12 Xterms (Kristian Köhntopp)
* David Haller schrieb am 11.Mai.2003:
On Sat, 10 May 2003, Bernd Brodesser wrote:
* David Haller schrieb am 09.Mai.2003:
On Fri, 09 May 2003, Bernd Brodesser wrote:
Ja. Aber C-a ist wirklich etwas ungeschickt, da einer der "Basis" Editierbefehle im emacs-Modus (und den vi-Modus will man auf der Kommandozeile ja selbst als vitischist nicht)...
Das behauptest Du immer wieder. Warum eigentlich?
Weil's grauslich ist. Ja, ich hab's mal getestet.
Du magst vi nicht.
An der Kommandozeile benutze ich nicht besonders viel, nur die Cursortasten Page up und down, Backspace natürlich und wenn es hoch kommt noch Home und End. Das war es aber auch schon. TAB natürlich auch.
Ich verwende da schon deutlich mehr, z.B. C-left (M-b, A-b), C-right (M-f, A-f), C-a statt "Home" (Pos1), C-e statt "End", C-w bzw. A-Backspace, C-k, C-u, A-d, A-l, A-u, sowie natuerlich Controlcodes wie C-v, C-s, C-q, C-d, C-c... Achso, C-j, C-m usw. funktionieren auch...
Ah ja.
screen haette z.B. A-a nehmen koennen,
Nein, hätte es nicht. screen reagiert nicht auf Tastendrücke, sondern auf ASCII-Zeichen. Eine häufige Anwendung von screen ist z.B die remoteanwendung. Welches ASCII-Symbol gibt denn A-a ab.
ESC a also "^[a" (siehe die Ausgabe von C-v A-a).
Auch das ist problematisch, da es aus zwei Zeichen besteht.
Achso, ich habe screen nichtmal installiert. Ich brauch das einfach nicht, mir reichen die Konsolen mit gpm[2] und normalerweise verwende ich eh X + WindowMaker als xterm-Multiplexer und fuer ein paar XEmacs-Fenster, siehe nicht-Zufallssig ;)
nun, wenn ich mehere Xterms habe, so ist das zwar gut und schön, aber ich muß ständig mit der Maus wechseln. Das ist sehr unschön. Einen Befehl im Hintergrund schicken ist nur schön, wenn er keine Ausgabe hat.
[2] wer mit C-z, bg, fg usw. umzugehen weiss... Ok, fuer remote Sachen wo man sonst nohup bemuehen muss... Aber dafuer nehm ich dann ggfs. z.B. ein scripterl das dann im bg laeuft, aber ich arbeite eh eher selten remote...
Ich arbeite zur Zeit häufig remote. Gibt es eine Möglichkeit, mit screen oder was auch immer, sowohl remote als auch lokal zu arbeiten? Mehere ssh zu eröffnen ist aber auch nicht so das wahre. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Hallo, On Wed, 14 May 2003, Bernd Brodesser wrote:
* David Haller schrieb am 11.Mai.2003:
On Sat, 10 May 2003, Bernd Brodesser wrote:
* David Haller schrieb am 09.Mai.2003:
On Fri, 09 May 2003, Bernd Brodesser wrote: [readline im vi-mode] Weil's grauslich ist. Ja, ich hab's mal getestet. Du magst vi nicht.
Stimmt. [..]
Achso, ich habe screen nichtmal installiert. Ich brauch das einfach nicht, mir reichen die Konsolen mit gpm[2] und normalerweise verwende ich eh X + WindowMaker als xterm-Multiplexer und fuer ein paar XEmacs-Fenster, siehe nicht-Zufallssig ;)
nun, wenn ich mehere Xterms habe, so ist das zwar gut und schön, aber ich muß ständig mit der Maus wechseln. Das ist sehr unschön.
Maus? Bist du jeck? Das war das erste was ich am WMaker eingestellt habe: die Tastenkombi um die Fenster zu wechseln (A-Tab). Und seit 0.80 kann WMaker auch das hin- und herwechseln zum jew. letzten aktiven, so dass man also bequem zwichen 2 xterms wechseln kann.
Einen Befehl im Hintergrund schicken ist nur schön, wenn er keine Ausgabe hat.
Dann schick die Ausgabe eben in ein logfile. Das musst du ja auch mit screen, wenn das Kommando mehr als ein paar wenige Zeilen Ausgabe erzeugt. Aber sowas will man ja eh nicht remote und nicht interaktiv verwenden. Jedenfalls: C-z reicht mir meistens wenn ich was remote mache. Und wenn man xemacs auch remote verwendet (geht auch via X) dann kann man da z.B. auch bequem ne manpage aufrufen o.ae. Leider ist "remote" nicht immer ein (x)emacs installiert. Kann man (wie) in vim z.B. auch ne manpage darstellen?
[2] wer mit C-z, bg, fg usw. umzugehen weiss... Ok, fuer remote Sachen wo man sonst nohup bemuehen muss... Aber dafuer nehm ich dann ggfs. z.B. ein scripterl das dann im bg laeuft, aber ich arbeite eh eher selten remote...
Ich arbeite zur Zeit häufig remote. Gibt es eine Möglichkeit, mit screen oder was auch immer, sowohl remote als auch lokal zu arbeiten?
Nicht dass ich wuesste. Daher: 2 xterms: einmal ssh user@host, und einmal lokal -- gut wenn dann die prompts lokal farbig sind und den hostnamen enthalten ;)
Mehere ssh zu eröffnen ist aber auch nicht so das wahre.
Ja. Geht aber problemlos. -dnh -- Aaaargh. Was war das denn? Schiss-Dur, oder Gugge-Moll? So schief gestrichen hat ja noch keiner. -- Jakob in dag°
Hallo David, hallo Leute, Am Donnerstag, 8. Mai 2003 03:10 schrieb David Haller:
On Thu, 08 May 2003, Christian Boltz wrote:
Am Dienstag, 6. Mai 2003 23:36 schrieb David Haller:
On Sun, 20 Apr 2003, Christian Boltz wrote:
cb@tux:/tmp> /sbin/fsck.ext2 testfs_buggy -f
*patsch*
*autsch*
*Eisbeutel-reich*
*LoL* Danke ;-)
Christian, bitte, Optionen _vor_ Argumenten! Was du daheim im stillen Kaemmerlein machst sei dir ueberlassen, aber wenn du hier (oder anderswo) schreibst, dann unterlasse bitte diese, aehm, hoeflich gesagt, Unsitte.
Mach ich ja üblicherweise[TM] ;-) In diesem Fall war es IIRC so, dass ich einfach <Cursor up> <space> -f <return> getippt habe, da kommt man eben zu solchen Befehlszeilen ;-)
Ja. Mach ich (aber nur selten!) so -- aber irgendwo in ne Mail oder nen script schreib ich sowas nicht! Es gibt eben haufenweise Anwendungen, die _nicht_ getopt verwenden, und dann schiesst du dir mit so einer Verwendung boes ins Knie. Ich hab mir stattdessen einfach "<up><C-a><A-f><space>" angewoehnt... (wobei aber die C- A- Kombinationen von mir eher als je 1 Tastendruck wahrgenommen werden).
Wie soll ich mir die Tastenkombinationen angewöhnen? Da sag ich der bash eher noch set -o vi und kann gemütlich weiterarbeiten ;-) Ich merke gerade, diese Methode hat noch einen Vorteil - statt Cursor-hoch kann ich einfach ESC k drücken. ;-) Hoffentlich kommt bald KDE 3.2, da soll endlich auch ein (k)vim-Modul für KMail dabei sein...
[Datei mit reiserfs] danach mit dem Hexeditor den Dateinamen (der übrigens zweimal zu finden war) geändert, und zwar an beiden Fundstellen einen "/" in den Namen eingebaut.
Ergebnis von fsck.reiserfs war, dass es nur mit --rebuild-tree die Möglichkeit gäbe, die Datei wiederherzustellen. Im Detail:
cb@tux:/tmp/tmp-cb/test> /sbin/reiserfsck testfs_buggy reiserfsck 3.6.4 (2002 www.namesys.com) [...] Checking internal tree..bad_directory_item: block 8211: The directory item [1 2 0x1 DIR (3)] has a not properly hashed entry (2) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!
Ist mir auch aufgefallen.
bad_leaf: block 8211, item 1: The corrupted item found (1 2 0x1 DIR (3), len 88, location 3964 entry count 3, fsck need 0, format old) [..] Nach dem --rebuild-tree lag die Datei dann mit einem völlig falschem Namen ("2_3" statt "das_ist_eine_testdatei") im lost+found des reiserfs :-|
[Diverse Erklärungen zu reiserfs und ext3] Interessant, danke für die Infos!
- da gefällt mir ext2 doch wesentlich besser ;-)
Mir auch, wobei, bis auf / und /home sind alle meine 11 Partitionen des Systems ext3. Und so langsam vertraue ich ext3 soweit, dass ich auch /home wohl noch umstelle :-)
Ich setze ext2 und ext3 schon fast gleich (wohl auch aus dem Grund, dass ext3 als ext2 mountbar ist) Meine Partitionen sind alle ext3, bisher völlig problemlos.
Auch heute wieder der Disclaimer: Bitte NICHT NACHMACHEN, insbesondere nicht auf "echten" Partitionen. Für einen evtl. Datenverlust durch obige Experimente und/oder Reperaturversuchen übernehme ich keine Haftung!
Lass ich sicherheitshalber stehen, da noch Teile meines Experiments oben stehen ;-)
-dnh, gib deinem sigmonster nen Keks mit Empfehlung von mir, ja?
Mach ich doch gern. Es hat sich sogar artig bedankt - siehe unten ;-) Gruß Christian Boltz -- Sach ma, siggst du alles von mir? ;) [David Haller in fontlinge-devel]
Hallo, On Fri, 18 Apr 2003, Christian Boltz wrote:
Am Donnerstag, 17. April 2003 03:49 schrieb David Haller:
On Thu, 17 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
On Wed, 16 Apr 2003, Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
BTW: Gute Idee ;-)
*g*
Was passiert eigentlich, wenn im Dateiname ein / auftaucht? [...] Das / könnte man im Dateinamen bekommen, wenn man hart auf die Device schreibt. vi /dev/hda1
Ouhauerha! *snigger*
Und gerade weil das so heimtückisch ist, probier ich es gleich mal aus (keine Angst, nur in einer "ext2-Datei" ;-) also nicht auf einer echten Partition.)
[Beispiel gesnippt] Nett :)))
Ich denke aber, wir sollten uns schon auf Dateinamen beschraenken, die sich auf legal via Kernel-VFS anlegen lassen...
Ooch, das ist ja langweilig *g*
Reicht aber voellig. Wer mit dem Hexeditor auf's FS losgeht ist ggfs. eh selber schuld und erntet von mir im Zweifelsfall nur ein haemisches Grinsen. "Uns"[tm] geht's ja um Dateinamen, die einem z.B. als Scriptprogrammierer begegnen koennten. -dnh PS: das ganze eignet sich dann auch als Test fuer Dateisysteme, deren Implementierung unter Linux und auch fuer Archivierungs- programme... -- I used to be a multiple personality, until we took a vote and decided we weren't. -- Stevo in the SDM
On Mit, 16 Apr 2003 at 10:04 (+0200), Bernd Brodesser wrote:
* David Haller schrieb am 16.Apr.2003:
On Tue, 15 Apr 2003, Jan Trippler wrote:
cnt=1 for file in "$@" do if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue
Und was ist mit Symlinks, Gerätedateien, Named Pipes und Sockets?
Die können verschoben werden. Es ging mir bei dem Verzeichnis-Ausschluss eigentlich nur darum, dass in der ersten Variante des Scripts eine flache Struktur in trash abgelegt wurde. Wenn man da jetzt Verzeichnisse mit reingenommen hätte, wäre das ein wenig Kuddelmuddel geworden. Da mir das nicht so gefallen hat, habe ich die 2. Variante (Ablage der Originalpfade) gebastelt. [...]
Ich muß gestehen, daß ich mir Euer Skript nicht so genau angesehen habe, und hier in der Mail ist es ja reichlich zerstückelt. Aber habt Ihr auch bedacht, daß eine Datei auch ein Hardlink haben kann? Im gleichen Verzeichnis oder in einem anderen? Wird wahrscheinlich auch nur in $trash verschoben. Ist das so gewollt?
Genau - und zwar nur der eine, der / die anderen bleiben stehen. Solange trash im gleichen Dateisystem wie die Hardlinks sind, bleibt auch der Linkcount erhalten, ansonsten wird der Link beim mv zerstört. Da steckt natürlich eine Gafahr drin.
Ich glaube, die ganze Verschieberrei wirft weit mehr Probleme auf, als es löst. Vor allem verläßt man sich darauf und wird schludrig bei der Verwendung von rm.
Prinzipiell ACK, nur _wenn_ man so ein Script baut, muss man vorher eben etwas nachdenken und mögliche Folgen bedenken. Das war der Hintergrund meiner Spielereien. Jan
Moin, On Mit, 16 Apr 2003 at 06:08 (+0200), David Haller wrote:
On Tue, 15 Apr 2003, Jan Trippler wrote: [...]
if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue
¿Por qué?
In dieser Variante war die Struktur in trash flach (Dateien werden da ja auch nicht mit ihren Pfaden gesichert), also fand ich es designmäßig ;-) daneben, Verzeichnisse mit reinzunehmen. [...]
if mv -i "$file" "$new" ## ich will immer noch auf der sicheren Seite ## sein, falls es zu einer Namenskollision kommt
Wenn Du meinst ;-) Ist natürlich sicherer, wenn z. B. mehrere Scripts gleichzeitig ins gleiche trash brezeln.
Ich hasse diese hirnrissige:
befehl if befehl_der_prueft_ob_befehl_ok; then ...
Ja ja, ich habe es einfach nur übernommen ;-) [...]
Fazit: $? ist in allen Faellen ueberfluessig, in denen man den Exit-status _nicht_ explizit einer benamsten Variablen zuweist oder z.B. mittels echo ausgibt.
Folgendes illustriert diese beiten Ausnahmen, in denen $? sinnvoll ist:
==== befehl befehl_status="$?" case $befehl_status in 1) ...;; 2) ...;; *) ...;; esac exit $befehl_status ====
Sinnvoll kann diese Zuweisung auch in folgendem Fall sein: for x in ir gend ei ne Sa mml ung; do tue_was_mit $x rc=$? raeume_auf_mit $x test $x -ne 0 && break done [...]
Jetzt kann höchstens noch die while-Schleife bis zum MAXINT laufen und dann das Script abbrechen, aber wenn dieser Fall eintritt, läuft eh was schief ;-)
Ajup. s.o.
Gibst Du immer so schnell auf? *g* [...]
cnt=1 for file in "$@" do if test -d "$file"; then newfn= newdn="$file" else newfn="`basename \"$file\"`" newdn="`dirname \"$file\"`" fi newdn="$trash`(cd \"$newdn\"; pwd)`"
*huch*[tm]. Da fehlt noch die Fehlerbehandlung, falls das cd fehlschlaegt... Und wozu die subshell?
Die Subshell ist doppelt gemoppelt, stimmt.
newdn="${trash}/`cd \"$newdn\" || exit -1; pwd -P`"
newdn="$trash`cd \"$newdn\" && pwd`" test "$newdn" = "$trash" && continue
Was hast du eigentlich gegen $(( ))?
Tradition ;-) Und wie wir mal vor ein paar Wochen gesehen haben, sind `` und $() eben doch nicht 100% gleich (wenn Du Dich nicht erinnern kannst, suche ich den Thread noch mal raus). `` funktioniert IMHO öfter als $().
Apropos shells: ich verwende das Teil auch viel zu selten, aber... [...] Allerdings ist die perlsh (ich hab' hier aber noch die vom 27.1.00) in Teilen noch recht unfertig und "alpha" oder so, und ob die noch ueberhaupt noch weiterentwickelt wird weiss ich auch nicht.
Fuer Perlianer ist perlsh aber ein nettes Spielzeug statt 'perl -e' ;)
Dann nehme ich aber lieber gleich perl. Immer schön trennen zwischen Perl und 'ner Shell - wo bleibt denn sonst der Spaß? [...]
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
Jut, könn' wa machn. Gehn wir zu Dir oder zu mir? :-) Ich baue gerade eine kleine Seite auf, wo das gut reinpassen tun täte. Jan
Hallo, On Wed, 16 Apr 2003, Jan Trippler wrote:
On Mit, 16 Apr 2003 at 06:08 (+0200), David Haller wrote:
On Tue, 15 Apr 2003, Jan Trippler wrote: [...]
if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue
¿Por qué?
In dieser Variante war die Struktur in trash flach (Dateien werden da ja auch nicht mit ihren Pfaden gesichert), also fand ich es designmäßig ;-) daneben, Verzeichnisse mit reinzunehmen.
Auch Verzeichnisse lassen sich umbenennen (aka Verschieben) :)
[...]
if mv -i "$file" "$new" ## ich will immer noch auf der sicheren Seite ## sein, falls es zu einer Namenskollision kommt
Wenn Du meinst ;-) Ist natürlich sicherer, wenn z. B. mehrere Scripts gleichzeitig ins gleiche trash brezeln.
Jo. Ich lass sowas einfach gern drin. Wenn's, wie "geplant" nicht auftaucht, dann merkt der Anwender nie was vom '-i', aber wenn's dann mal noetig waere, dann ist's schoen es drin zu haben, IMO ;) Naja, wir sind uns ja eh einig, dass das script sowieso Unfug ist ;) rm is rm, weg is weg; und gut is ;) Wer nich loeschen will, der soll bitteschoen auch selber schreiben, was er will, also z.B. ein 'mv -i blubb ~/trash'.
Ich hasse diese hirnrissige:
befehl if befehl_der_prueft_ob_befehl_ok; then ...
Ja ja, ich habe es einfach nur übernommen ;-)
Jaja... ;))
[...]
Fazit: $? ist in allen Faellen ueberfluessig, in denen man den Exit-status _nicht_ explizit einer benamsten Variablen zuweist oder z.B. mittels echo ausgibt.
Folgendes illustriert diese beiten Ausnahmen, in denen $? sinnvoll ist:
==== befehl befehl_status="$?" case $befehl_status in 1) ...;; 2) ...;; *) ...;; esac exit $befehl_status ====
Sinnvoll kann diese Zuweisung auch in folgendem Fall sein: for x in ir gend ei ne Sa mml ung; do tue_was_mit $x rc=$? raeume_auf_mit $x test $x -ne 0 && break done
Und wo machst du dann noch was mit $rc? Oder hast du das nur vergessen? ;) Und ja, prinzipiell ist das einer der Faelle (wie oben bei mir beim case), wo man anschliessend noch was mit dem exit-status machen will. Also ist dein Beispiel nur ne andere Variante dieser Ausnahme: ==== befehl status=$? machwasanderes_das_$?_aendert machwasmit $status ====
[...]
Jetzt kann höchstens noch die while-Schleife bis zum MAXINT laufen und dann das Script abbrechen, aber wenn dieser Fall eintritt, läuft eh was schief ;-)
Ajup. s.o.
Gibst Du immer so schnell auf? *g*
Nicht immer, aber immer oefter? *g*
[...]
cnt=1 for file in "$@" do if test -d "$file"; then newfn= newdn="$file" else newfn="`basename \"$file\"`" newdn="`dirname \"$file\"`" fi newdn="$trash`(cd \"$newdn\"; pwd)`"
*huch*[tm]. Da fehlt noch die Fehlerbehandlung, falls das cd fehlschlaegt... Und wozu die subshell?
Die Subshell ist doppelt gemoppelt, stimmt.
newdn="${trash}/`cd \"$newdn\" || exit -1; pwd -P`"
newdn="$trash`cd \"$newdn\" && pwd`" test "$newdn" = "$trash" && continue
*AUTSCH* Ja!!1 Ich glaube, wir sollten immer die scripte vom jew. anderen gegenlesen lassen ;)) Den Sonderfall $newdn = $trash hab ich uebersehen. Und wenn das 'cd' scheitert, haben wir immer "$trash" als "$newdn"... Da ist das `||exit x` also tatsaechlich ueberfluessig.
Was hast du eigentlich gegen $(( ))?
Tradition ;-) Und wie wir mal vor ein paar Wochen gesehen haben, sind `` und $() eben doch nicht 100% gleich (wenn Du Dich nicht erinnern kannst, suche ich den Thread noch mal raus). `` funktioniert IMHO öfter als $().
'$(( ))' != '$( )' '$(( ))' ist aequivalent zu '$[ ]', '$()' (annaehernd) zu '``'....
Apropos shells: ich verwende das Teil auch viel zu selten, aber... [...] Allerdings ist die perlsh (ich hab' hier aber noch die vom 27.1.00) in Teilen noch recht unfertig und "alpha" oder so, und ob die noch ueberhaupt noch weiterentwickelt wird weiss ich auch nicht.
Fuer Perlianer ist perlsh aber ein nettes Spielzeug statt 'perl -e' ;)
Dann nehme ich aber lieber gleich perl. Immer schön trennen zwischen Perl und 'ner Shell - wo bleibt denn sonst der Spaß?
Aber die perlsh ist erstens ein nettes Spielzeug(!), und zweitens u.U. praktischer ;) Du schreibst doch sicher auch nicht immer alles in ein script in ~/bin, sondern gibst, zumindest teilweise erstmal direkt in eine interaktive shell ein ;) Kurz: "Kannstu perl? muttu perlsh spielen!"
[...]
PS: Jan, solle' mer mal unsere "fiesen" Dateinamen sammeln und als tarball wo ablegen?
Jut, könn' wa machn. Gehn wir zu Dir oder zu mir? :-) Ich baue gerade eine kleine Seite auf, wo das gut reinpassen tun täte.
Hmjo ;) Gern. Bei mir passt's zwar auch, und ich will eh im Laufe der Aktualisierung auch eine Rubrik "Scripts und Verwandtes" aufmachen[1]... Wie waere's wenn wir den tarball gegenseitig spiegeln? -> weiteres per PM? "Master" kannst gern du sein, wie ich mich kenne, bin ich bald froh drum, mich nicht kuemmern zu sollen ;) Ok, jedenfalls, ich erneuere also mal mein "kranke_dateinamen" -Verzeichnis, da hab ich zwischendurch mal alles geloescht... ;) Apropos: perl -e 'mkdir("./~")' kann "interessante" Auswirkungen haben... (perl oder die ash hilft bei der Beseitigung ;) -dnh, dessen HP inzwischen so veraltet ist, dass es nicht mal das schaemen mehr lohnt ;) Das Update ist aber nach wie vor und immer wieder in Arbeit :)) [1] mit den Jahren hat sich die ein oder andere "Perle" gefunden ;) -- Do infants have as much fun in infancy as adults do in adultery?
Hallo David, hallo Leute, Am Donnerstag, 17. April 2003 05:09 schrieb David Haller:
Apropos: perl -e 'mkdir("./~")' kann "interessante" Auswirkungen haben...
Dein Befehl verrät ja schon die Lösung ;-) Geht auch "einfacher" mit perl -e 'mkdir("~")' oder in der Bash mkdir ./~ oder mkdir "~" ;-)
(perl oder die ash hilft bei der Beseitigung ;)
Wieso perl? Einfach rmdir ./~ oder rmdir "~" eingeben. Wichtig ist eben nur, dass die Tilde nicht am Anfang steht (./~) oder mit "~" gequotet wird. Gruß Christian Boltz -- Es kann dadurch , daß der Rechner ( wenn er an Trenn - zeichen umbricht [Ratti erklärt ) die falschen Stellen den Begriff erwischt , zu ganz gräß "Plenken" - lichen Effekten kommen in suse-linux] !
Hallo, On Fri, 18 Apr 2003, Christian Boltz wrote:
Am Donnerstag, 17. April 2003 05:09 schrieb David Haller:
Apropos: perl -e 'mkdir("./~")' kann "interessante" Auswirkungen haben...
Dein Befehl verrät ja schon die Lösung ;-) Geht auch "einfacher" mit perl -e 'mkdir("~")' oder in der Bash mkdir ./~ oder mkdir "~" ;-)
(perl oder die ash hilft bei der Beseitigung ;)
Wieso perl? Einfach rmdir ./~ oder rmdir "~" eingeben.
Stimmt. Gerade getestet.
Wichtig ist eben nur, dass die Tilde nicht am Anfang steht (./~) oder mit "~" gequotet wird.
Hatte ich, hatte ich! dh@slarty[5]: /tmp/test2 (0)$ mkdir '~' dh@slarty[5]: /tmp/test2 (0)$ ls ~ dh@slarty[5]: /tmp/test2 (0)$ ls ~/ [snip liste des $HOME-Verz.] dh@slarty[5]: /tmp/test2 (0)$ ls -al '~/' total 8 drwxr-xr-x 2 dh dh 4096 May 6 23:46 . drwxr-xr-x 3 dh dh 4096 May 6 23:46 .. Hm... Dann war neulich, wo ich's _nicht_ loeschen konnte, wirklich irgendwas verkorkst... Naja, is aber schon lustig, wenn man z.B. mit dem 'mc' im $HOME landet ;) -dnh -- Meine sigg macht Urlaub bis Donnerstag. [WoKo in dag°]
On Don, 17 Apr 2003 at 05:09 (+0200), David Haller wrote:
Hallo,
On Wed, 16 Apr 2003, Jan Trippler wrote:
On Mit, 16 Apr 2003 at 06:08 (+0200), David Haller wrote:
On Tue, 15 Apr 2003, Jan Trippler wrote: [...]
if test -d "$file"; then echo "Verzeichnisse können nicht nach $trash verschoben werden" continue
¿Por qué?
In dieser Variante war die Struktur in trash flach (Dateien werden da ja auch nicht mit ihren Pfaden gesichert), also fand ich es designmäßig ;-) daneben, Verzeichnisse mit reinzunehmen.
Auch Verzeichnisse lassen sich umbenennen (aka Verschieben) :)
Ja, aber dann hast Du in trash eine tree-Struktur, was vom ursprünglichen Ansatz her nicht vorgesehen war. Das es geht, ist schon klar. [...]
Sinnvoll kann diese Zuweisung auch in folgendem Fall sein: for x in ir gend ei ne Sa mml ung; do tue_was_mit $x rc=$? raeume_auf_mit $x test $x -ne 0 && break done
Und wo machst du dann noch was mit $rc? Oder hast du das nur vergessen? ;) Und ja, prinzipiell ist das einer der Faelle (wie oben bei mir beim case), wo man anschliessend noch was mit dem exit-status machen will. Also ist dein Beispiel nur ne andere Variante dieser
Ärks - Buchwechsel verstapelt. So sollte es aussehen: for x in ir gend ei ne Sa mml ung; do tue_was_mit $x rc=$? raeume_auf_mit $x test $rc -ne 0 && break # ^^ dös meinte ich done # und dann vielleicht noch ein gepflegtes: if test $rc -ne 0; then mache_ein_tolles_fehlerhandling_und_tschuess fi [...]
Gibst Du immer so schnell auf? *g*
Nicht immer, aber immer oefter? *g*
Weichei! Jeansbügler! Freundinnen-Rechtgeber! ;-) [Perverse Dateinamen-Sammlung]
Hmjo ;) Gern. Bei mir passt's zwar auch, und ich will eh im Laufe der Aktualisierung auch eine Rubrik "Scripts und Verwandtes" aufmachen[1]... Wie waere's wenn wir den tarball gegenseitig spiegeln? -> weiteres per PM? "Master" kannst gern du sein, wie ich mich kenne, bin ich bald froh drum, mich nicht kuemmern zu sollen ;)
Jau, dann tun wir mal so.
-dnh, dessen HP inzwischen so veraltet ist, dass es nicht mal das schaemen mehr lohnt ;) Das Update ist aber nach wie vor und immer wieder in Arbeit :))
Das habe ich bei meinem letzten Besuch gemerkt und kann Dir da nur zustimmen *duck_und_weg* Jan
Hallo, On Thu, 17 Apr 2003, Jan Trippler wrote:
On Don, 17 Apr 2003 at 05:09 (+0200), David Haller wrote:
Hallo,
On Wed, 16 Apr 2003, Jan Trippler wrote: [...]
Sinnvoll kann diese Zuweisung auch in folgendem Fall sein: for x in ir gend ei ne Sa mml ung; do tue_was_mit $x rc=$? raeume_auf_mit $x test $x -ne 0 && break done
Und wo machst du dann noch was mit $rc? Oder hast du das nur vergessen? ;) Und ja, prinzipiell ist das einer der Faelle (wie oben bei mir beim case), wo man anschliessend noch was mit dem exit-status machen will. Also ist dein Beispiel nur ne andere Variante dieser
Ärks - Buchwechsel verstapelt. So sollte es aussehen: for x in ir gend ei ne Sa mml ung; do tue_was_mit $x rc=$? raeume_auf_mit $x test $rc -ne 0 && break # ^^ dös meinte ich wos moanst? 'test $rc -eq 0 || break;' *eg*[1] done
Jup. Wobei 'raeume_auf_mit $x' natuerlich unabhaengig von 'tue_was_mit $x' sein muss. Sonst muss man das abfangen bzw. je nach Bedarf nur bei Erfolg von tue_was_mit ausfuehren: if tue_was_mit $x; then raeume_auf_mit $x else break fi Falls man auch bei Misserfolg von tue_was_mit mit raeume_auf_mit aufraeumen kann, dann spricht natuerlich nix gegen deine Variante ;)
# und dann vielleicht noch ein gepflegtes: if test $rc -ne 0; then mache_ein_tolles_fehlerhandling_und_tschuess fi
Ajup :)
[...]
Gibst Du immer so schnell auf? *g*
Nicht immer, aber immer oefter? *g*
Weichei!
Ach? Sind deine schon vertrocknet?
Jeansbügler!
Isch 'abe geine Buegeleisen!
Freundinnen-Rechtgeber!
Welcher?
;-)
;))
[Perverse Dateinamen-Sammlung] [->PM]
-dnh, dessen HP inzwischen so veraltet ist, dass es nicht mal das schaemen mehr lohnt ;) Das Update ist aber nach wie vor und immer wieder in Arbeit :))
Das habe ich bei meinem letzten Besuch gemerkt und kann Dir da nur zustimmen *duck_und_weg*
Tu poeser Pursche tu! -dn'*WattebaeuschchenhinterherwerfundeinenKaktussuchend*'h PS: F'up! [1] das is ne Geschmackssache, ja. -- "Wirklich praxisnah wären Münzen zu EUR 0,99." -- Wolfgang Schwanke in de.etc.sprache.deutsch
Hallo David, Ich habe es so eingebaut wie du es vorgeschlagen hast. Bringen uns sollte sachen nicht weiter als wenn wie bei mir zuerst alles weck ist. Es ist fast eine Woche . Das war ein Schwarzer Freitg für mich. ;-(( #!/bin/bash # shells srm # Mit der Freundliche Hilfe der SuSE Liste #----------------------------------------------------------------------- # Über ein Script in cron /etc/cron.monthly/Papierkorb aufgeräumt. #_______________________________________________________________________ trash=$HOME/Papierkorb; test -d $trash || mkdir $trash || exit 1 # for file in "$@" do new="$trash/$$-$file" if mv -i "$file" "$new" then echo "$file wurde nach $new verschoben" else echo "Kann $file nicht in den Papierkorb verschieben" fi done Ich danke euch alle für die Konstruktive Anregung. Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
On Don, 17 Apr 2003 at 09:58 (+0200), Patrice Staudt wrote: [...]
Ich danke euch alle für die Konstruktive Anregung.
Hmm, und warum machst Du dann Dein Script nicht entsprechend unseren Anregungen ein wenig sicherer (zumindest um den Fall abzufangen, dass der Benutzer Dateinamen angibt, die _nicht_ im aktuellen Verzeichnis liegen oder das Umbenennen bei gleichnamigen Dateien zu ermöglichen)? Na, scheint Dir ja egal zu sein, schade um die verplemperte Zeit. Jan
* Andreas Scherer schrieb am 14.Apr.2003:
Am Sonntag, 13. April 2003 18:49 schrieb Jan Trippler:
Zum Script: Patrice, hast Du das schon mal für Dateien mit Leerzeichen oder anderen Sonderzeichen im Namen versucht?
jan@k500:~/tmp/del> ll insgesamt 4 -rw-r--r-- 1 jan users 0 Apr 13 18:46 * -rw-r--r-- 1 jan users 0 Apr 13 18:46 Datei mit Leerzeichen -rwxr-xr-x 1 jan users 115 Apr 13 18:48 del
Na ja, solche Dateien sollte es auf einem *nix-Systen doch eigentlich nicht geben? Oder?
Spielende Kinder haben doch eigentlich nichts auf der Straße zu suchen. Warum muß ein Autofahrer trotzdem darauf Acht geben? Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Hallo ,
Viel Sinnvoller ist es, sich anzugewöhnen, genau nachzudenken, wenn man rm benutzt.
Naturlich es es sinnvoller, nur es es passiert macht es .... Da ist so eine Hilfe sinnvoll da keine Katastrophe zu haben. Die Platten sind ausreichend groß und eine Automatische reinigung habe ich schon für die Windows Share. Grüße Patrice -- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
Hallo Zusammen , Gibt es ein möglichkeit undo delete sogar Win kann so was. Welche FS kann dies, unter Linux?? Ich habe die /etc gelöscht wie kann ich sie wieder restorieren ;-(((
1. Kein Schreibzugriff mehr auf die Partition.
Ich mußte sie ausmachen da ich keine Email Kontakt mehr hatte.
2. reiserfsck --rebuild-tree probieren.
Habe ich gemacht ohne erfolgt, die Diskution geht seit Januar durch die Liste wie ein Undelte gehen soll. Ist ein Anderes FS besser dafür vorbereitet?? Was kann ich noch versuchen?? Wenn ich es mit dem Update überschreibe dann komme ich auch nicht mehr an die Arbeit der 5 Letzte Tage!! ;-((( Er legt effectiv beim sck ein Directorie Lost+Found an wie es Ext2 Standart Mässig anlegt. Aber das rebuild kann doch kein undelete, oder was habe ich da falsch verstanden?
Noch ein Idee
Grüße Patrice
-- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
-- Patrice Staudt Linux System, Wintringerstraße 67,D-66271 Kleinblittersdorf Tel: 06805-3286, http://engsystem.net/
* Patrice Staudt schrieb am 11.Apr.2003:
Habe ich gemacht ohne erfolgt, die Diskution geht seit Januar durch die Liste wie ein Undelte gehen soll. Ist ein Anderes FS besser dafür vorbereitet??
Wenn der letzte Hardlink auf einer Datei gelöscht wird, so wird diese Datei freigegeben. Wenn man eine neue Datei schreiben will, dann wird auf die freien Blöcke zugegriffen, also die, die gelöscht wurden. Dabei wird versucht die Blöcke möglichst nacheinander zu beschreiben. Jedenfalls wird wohl nicht darauf Rücksicht genommen, welcher Block zuletzt gelöscht wurde. Das ist ja wohl absolut nachrangig. Wenn man dann auch noch bedenkt, daß Linux ein Mehrbenutzer Betriebssystem ist, wo also viele Leute gleichzeitig neue Dateien anlegen können, bzw. alte Dateien vergrößern, so wird so schnell sicher nicht allzuviel Wert auf ein undelete gelegt, da es sowieso oft nicht funktionieren wird, da sehr schnell schon ein Block beschrieben wird.
Was kann ich noch versuchen??
In der /etc handelt es sich ja meinst um ASCII-Dateien. Die kann man in der Device selber evtl. wiederfinden. Das beste wird wohl sein, Dein letztes Backup wieder einzuspielen und die Änderungen neu zu machen. Wenn Du das dd auf eine CD oder ähnliches gemacht hast, kannst Du auf dieser CD ja suchen, wenn es auf einem Band ist, ist es natürlich schwieriger. Dann kanst Du dies zwar wieder auf Festplatte legen, aber mit den Änderungen, die Du machen mußt, kanst Du genau die Daten löschen, die Du brauchst. Vielleicht hast Du ja noch was Plattenplatz. Wenn Du die kaputte Version auf CD oder auf der Festplatte hast, so kanst Du die Partiton ja einfach absuchen, etwa less -f /dev/hdaX oder wie die Partition auch heißen mag. Da kanst Du denn ganz normal suchen. Allerdings ist diese Datei sehr groß, es ist die ganze Partition. Und auf keinen Fall was darin schreiben, dann machst Du alles kaputt. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht widerstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
participants (11)
-
Andreas Feile -
Andreas Scherer -
B.Brodesser＠t-online.de -
Christian Boltz -
David Haller -
Jan.Trippler＠t-online.de -
Joerg Rossdeutscher -
Kristian Koehntopp -
Patrice Staudt -
Peter Wiersig -
Thomas Hertweck