Wegstaben V. schrieb:> Mit einer GUI Applikation die Datei umbenennen auf etwas weniger> problematisches. Dann entfernen
Ist mir leider auf einem Raspberry pi ohne Graphical User Interface
passiert.
Wenn Du die inode herrausgefunden hast, dann löscht Du sie über den find
Befehl:
1
find . -inum 16011003 -exec rm -i {} \;
Bei mir war die inode 16011003, Deine wird logischerweise anders sein.
Aus Sicherheitsgründen wird rm mit der Option -i verwendet, d.h. Du
musst jede gelöschte Datei bestätigen.
Und nicht in Panik geraten: Der find Befehl kann etwas länger dauern.
> To remove a file whose name starts with a '-', for example '-foo', use
2
> one of these commands:
3
>
4
> rm -- -foo
5
> rm ./-foo
6
>
;-)
Der Vollständigkeit halber sei erwähnt, daß es in den Repositories
vieler Distributoren das Paket "detox" mit dem Programm detox(1) gibt,
das "böse" Zeichen aus Dateinamen entfernt.
Die gehobene Fragestellung ist, wie man ein File weg bekommt, dessen
Name die Länge 0 hat. Das hatte ich vor langer Zeit in AIX und
beschloss, damit zu leben.
(prx) A. K. schrieb:> Die gehobene Fragestellung ist, wie man ein File weg bekommt, dessen> Name die Länge 0 hat. Das hatte ich vor langer Zeit in AIX und> beschloss, damit zu leben.
Und das ging nicht über den Inode? 8-O
Ein T. schrieb:> Und das ging nicht über den Inode? 8-O
Weiss ich nicht mehr, ist zig Jahre her. Vielleicht hatte ich es nicht
versucht. Jedenfalls ging es nicht über den Namen, weil das Prinzip, mit
dem Pfade im Kernel abgearbeitet werden, das nicht ermöglichte.
(prx) A. K. schrieb:> Die gehobene Fragestellung ist, wie man ein File weg bekommt, dessen> Name die Länge 0 hat. Das hatte ich vor langer Zeit in AIX und> beschloss, damit zu leben.
Eine vorangehende Frage wäre, wie man so eine Datei überhaupt erstellt.
Evtl. liefert die Antwort auf diese Frage auch einen Hinweis darauf, wie
die Datei wieder gelöscht werden kann.
Yalu X. schrieb:> Eine vorangehende Frage wäre, wie man so eine Datei überhaupt erstellt.
Hatte ich mich auch gefragt. Aber die Datei war ein zufälliges
"Fundstück", kein Nebeneffekt irgendwelche bewusster Experimente. Bei
JFS sollte das auch nicht als Nebeneffekt von Hardware-Events möglich
sein.
(prx) A. K. schrieb:> Ein T. schrieb:>> Und das ging nicht über den Inode? 8-O>> Weiss ich nicht mehr, ist zig Jahre her. Vielleicht hatte ich es nicht> versucht. Jedenfalls ging es nicht über den Namen, weil das Prinzip, mit> dem Pfade im Kernel abgearbeitet werden, das nicht ermöglichte.
Ja, natürlich... Ach, ich wußte schon, warum AIX und ich in diesem Leben
sicherlich keine innigen Freunde mehr werden. ;-)
Die korrekte Antwort rm -- filename wurde schon gegeben.
Ich möchte noch etwas Unix-Basics hinzufügen, das ist nämlich kein
Zufall, daß das so funktioniert.
Normalerweise werden Optionen mit getopt(3) oder einer verwandten
Library geparsed. Und dort gilt: Sobald "--" gefunden wird, werden die
folgenden Argumente nicht mehr als Optionen gelesen.
Literatur: man getopt
GUI oder Inode-Magie wird nicht benötigt.
Dazu, wie man einen directory entry mit leerem Filenamen zusammenbringt
(egal ob Linux, BSD oder AIX, das zu seiner Zeit durchaus attraktiv war
und dem wir beispielsweise den heutigen lvm verdanken), fällt mir
allerdings zumindest mit Shell-Mitteln auch nichts ein.
Gerald K. schrieb:> sudo rm -L-.-..log> rm: invalid option -- 'L'> Try 'rm ./-L-.-..log' to remove the file '-L-.-..log'.> Try 'rm --help' for more information.>> Geht leider nicht.
Du hast aber schon diese lustigen kleinen Dinger ›'‹ gesehen welche den
Dateinamen umschließen?
Edit: Und natürlich das ›--‹
Alexander T. schrieb:> Dazu, wie man einen directory entry mit leerem Filenamen zusammenbringt> (egal ob Linux, BSD oder AIX, das zu seiner Zeit durchaus attraktiv war> und dem wir beispielsweise den heutigen lvm verdanken), fällt mir> allerdings zumindest mit Shell-Mitteln auch nichts ein.
Ich habe gerade mal versucht, eine bestehende Datei in '' umzubenennen,
indem ich im vorher abgemounteten Ext4-Filesystem mit dem Hexeditor
einfach die Länge des Dateinamens auf 0 gesetzt habe. Versuche ich das
Verzeichnis mit ls aufzulisten, erscheint zunächst die Fehlermeldung
"bad message", was aber wohl daher kommt, dass wegen der Änderung im
entsprechenden Directory-Block die Prüfsumme nicht mehr stimmt. Eine
Prüfung mit e2fsck gibt die folgenden Fehler aus:
Lasse ich nur die Prüfsumme korrigieren, führt ein erneutes ls zu einem
I/O-Error. Lasse ich auch die Zero-Length-Fehler korrigieren, werden die
entsprechenden Directory-Einträge einfach gelöscht.
Yalu X. schrieb:> Lasse ich auch die Zero-Length-Fehler korrigieren, werden die> entsprechenden Directory-Einträge einfach gelöscht.
Und nichts im lost+found?
Norbert schrieb:> Yalu X. schrieb:>> Lasse ich auch die Zero-Length-Fehler korrigieren, werden die>> entsprechenden Directory-Einträge einfach gelöscht.>> Und nichts im lost+found?
Doch, natürlich. Dort findet sich die Datei als #<inode-nummer> wieder
(wie auch in deinem eigenen Versuch in deinem nächsten Beitrag). Aber
der Directory-Eintrag mit dem leeren Dateinamen ist weg, und der leere
Dateiname wurde auch nicht ins lost+found übernommen.
Das (nicht erreichte) Ziel meiner Versuche war es ja, das Filesystem so
zu manipulieren, dass am Ende folgendes möglich ist:
Als nächstes hätte man sich dann dann dieser Frage zuwenden können:
(prx) A. K. schrieb:> Die gehobene Fragestellung ist, wie man ein File weg bekommt, dessen> Name die Länge 0 hat. Das hatte ich vor langer Zeit in AIX und> beschloss, damit zu leben.
Am besten natürlich mit regulären Shell-Mitteln und ohne direkte
Manipulation des Filesystems.
Aber das Ansinnen, eine Datei mit leerem Dateinamen zu erzeugen, scheint
– zumindest unter Linux mit Ext4-Filesystem – bereits nachhaltig im Keim
erstickt zu werden.
Yalu X. schrieb:> Aber das Ansinnen, eine Datei mit leerem Dateinamen zu erzeugen, scheint> – zumindest unter Linux mit Ext4-Filesystem – bereits nachhaltig im Keim> erstickt zu werden.
Ja das stimmt, zumal ja sämtliche Zeichen außer Path-Separator und
0x00 erlaubt sind. Damit käme (absolut betrachtet) der <NULL>-String dem
Verzeichnispfad gleich und das mag das System so gar nicht. Dieser Colt
schießt nicht in den eigenen Fuß!
Auch nett, diesmal hauptsächlich in Windows, sind Files mit Leerzeichen
hinten dran. Man kann die problemlos erzeugen und wieder löschen - aber
nicht so, wie man es gewohnt ist. Auf den üblichen Wegen genutzt, kann
man damit Leute zur Verzweiflung bringen, denn darin werden solche
Leerzeichen im Aufruf automatisch entfernt, bevor das Filesystem den
Namen sieht.
Windows … Ich muss immer schmunzeln wenn jemand im Explodierer - oder
wie das Ding heißt - bei einer Datei nur Groß- und Kleinschreibung
ändern will.
Umbenennen - Case ändern. Enter. Verdammt.
Umbenennen - Case ändern und zB. ein X dran hängen. Enter.
Umbenennen - X wieder wegnehmen. Enter.
Wer denkt sich so etwas aus?
Norbert schrieb:> Wer denkt sich so etwas aus?
Kudos letztlich an Tim Paterson und Gary Kildall. Will man mit
Filesystemen kompatibel sein, die nicht zwischen Klein- und
Grossschreibung unterscheiden, ist das nur konsequent.
Als Administrator auszuführen:
Norbert schrieb:> Explodierer
Als ich mal testen wollte, welche Dateinamen in Windows erlaubt sind,
habe ich von einem Linux-Client aus auf einem Server mit NTFS
erfolgreich eine Datei namens "..." angelegt, was ja unter Linux nichts
Besonderes und auch in Windows nicht explizit verboten ist. Leider habe
ich vergessen, das Verzeichnis mit den Testdateien direkt wieder zu
löschen.
Etwa ein Jahr später erhielt ich von einem für den Server zuständigen
IT-Kollegen einen aufgeregten Anruf: Anlässlich der Installation einer
neuen Serverhardware wollte er die Daten umkopieren, was aber trotz
mehrerer Versuche immer an einer ganz bestimmten meiner Dateien
scheiterte. Erst war ich etwas verwundert, dann erinnerte ich mich
wieder an den Test und habe die Datei natürlich sofort gelöscht ;-)
Mittlerweile wird das Anlegen solcher Dateien serverseitig unterbunden.
Ähnliche Probleme gab es mit stark verschachtelten Verzeichnisstrukturen
und der damit verbundenen Gesamtpfadlänge von mehr als 260 Zeichen, die
zwar in NTFS angelegt werden konnten, dem Explorer aber große Probleme
bereiteten. M.W. ist auch dieses Problem inzwischen zumindest teilweise
behoben bzw. durch Workarounds umgehbar.
(prx) A. K. schrieb:> Die gehobene Fragestellung ist, wie man ein File weg bekommt,> dessen> Name die Länge 0 hat. Das hatte ich vor langer Zeit in AIX und> beschloss, damit zu leben.
rm -Rf .. ;-)
Yalu X. schrieb:> Ähnliche Probleme gab es mit stark verschachtelten Verzeichnisstrukturen> und der damit verbundenen Gesamtpfadlänge von mehr als 260 Zeichen, die> zwar in NTFS angelegt werden konnten, dem Explorer aber große Probleme> bereiteten. M.W. ist auch dieses Problem inzwischen zumindest teilweise> behoben bzw. durch Workarounds umgehbar.
Liegt die Grenze in Win nicht schon seit ewigen Zeiten bei 1k direkt
adressierbarer Pfad/File-Länge?
Klar, viele Tools sind da nicht mitgewachsen, und verstehen immer noch
nur 256 lange Pfade.
Aber üblicherweise kann man ja solche überlangen Pfade auch step by step
entlang hangeln, und dann dort sein Unwesen treiben ...
Norbert schrieb:> Windows … Ich muss immer schmunzeln wenn jemand im Explodierer - oder> wie das Ding heißt - bei einer Datei nur Groß- und Kleinschreibung> ändern will.>> Umbenennen - Case ändern. Enter. Verdammt.
Wurde hier auf dem Arbeitsrechner (glaub Win 10) gerade erfolgreich
getestet.
Was hätte denn passieren sollen?
Le X. schrieb:> Was hätte denn passieren sollen?
›Abcde‹ -> ›abcde‹ ging zumindest bis W7 nicht ohne Zwischenschritt.
Man musste also:
›Abcde‹ -> ›abcdeX‹
›abcdeX‹ -> ›abcde‹
Wenn's nun sofort funktioniert, ist doch super.
Dann haben sie's nach nur wenigen Jahrzehnten endlich repariert.
Rolf M. schrieb:> Die Längenbeschränkung liegt wohl nicht bei 256, sondern lustigerweise> bei 260.
Vermutlich wegen der Extension. Ich glaube, früher war der Dateityp auch
nicht auf allen Systemen teil des Dateinamens (z.B. bei MacOS). Und bei
FAT12 auf Disketten ist die Extension ein separates 3 Zeichen Feld. 1
Byte für die Dateinamenlänge sind maximal 256 Bytes, dazu 3 für die
Extension und ein Byte für den `.` sind 260 bytes.
https://www.eit.lth.se/fileadmin/eit/courses/eitn50/Literature/fat12_description.pdf
Jens G. schrieb:>> Name die Länge 0 hat. Das hatte ich vor langer Zeit in AIX und>> beschloss, damit zu leben.>> rm -Rf .. ;-)
Wenn eine Löschung zu Fuss nicht geht, dann geht das auch nicht. Denn
das arbeitet auch auf Pfad-Ebene.
Nö, wenn schon. dann richtig: mkfs.
Beitrag "Re: Datei unter Linux entfernen?"
Ist wohl die sicherste Methode. kann man natürlich noch beschleunigen
mit -maxdepth 1 und wenn man auf die Einzelbestätigung verzichten kann,
statt -exec einfach direkt das -delete flag benutzen.
Thread beobachten
Seitenaufteilung abschalten