Wie kann ich unter linux die Datei mit dem Namen "-L-.-..log" entfernen?
1 |
|
2 |
|
3 |
|
4 |
|
Mit einer GUI Applikation die Datei umbenennen auf etwas weniger problematisches. Dann entfernen
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.
Probiere mal rm "'-L-.-..log'"
gab bei mir zummindest nicht die Meldung über "ungültige Option", sondern "Datei nicht gefunden".
Du schaust, welche inode die datei hat:
1 |
|
Wenn Du die inode herrausgefunden hast, dann löscht Du sie über den find Befehl:
1 |
|
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.
Ganz einfach mit
1 |
|
1 |
|
2 |
|
3 |
|
4 |
|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
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.
Ganz einfach mit sudo rm -- '-L-.-..log'
Und für die ganz Ängstlichen noch in 'Interactive':
1 |
|
Wie kann ich unter linux die Datei mit dem Namen "-L-.-..log" entfernen?
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
Hast Du den Vorschlag 'rm ./-L-.-..log' probiert?
Weshalb wird hier soviel Wind um eine vollkommen triviale Aufgabe gemacht?
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
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
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.
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.
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.
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.
Ganz einfach mit
sudo rm -- '-L-.-..log'
1 |
|
2 |
|
3 |
|
4 |
|
Geht leider nicht.
Aber der Hinweis Try ... half.
Danke an euch Allen.
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 ›--‹
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:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
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.
Lasse ich auch die Zero-Length-Fehler korrigieren, werden die entsprechenden Directory-Einträge einfach gelöscht.
Und nichts im lost+found?
Mit ext2 getestet. Geht auch nichts verloren. Hatte mich schon erschreckt! ;-)
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
18 |
|
19 |
|
20 |
|
21 |
|
22 |
|
23 |
|
24 |
|
25 |
|
26 |
|
27 |
|
28 |
|
29 |
|
30 |
|
31 |
|
32 |
|
33 |
|
34 |
|
35 |
|
36 |
|
37 |
|
38 |
|
39 |
|
40 |
|
41 |
|
42 |
|
43 |
|
44 |
|
45 |
|
46 |
|
47 |
|
48 |
|
49 |
|
50 |
|
51 |
|
52 |
|
53 |
|
54 |
|
55 |
|
56 |
|
57 |
|
58 |
|
59 |
|
60 |
|
61 |
|
62 |
|
63 |
|
64 |
|
65 |
|
66 |
|
67 |
|
68 |
|
69 |
|
70 |
|
71 |
|
72 |
|
73 |
|
74 |
|
75 |
|
76 |
|
77 |
|
78 |
|
79 |
|
80 |
|
81 |
|
82 |
|
83 |
|
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:
1 |
|
2 |
|
3 |
|
4 |
|
Als nächstes hätte man sich dann dann dieser Frage zuwenden können:
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.
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?
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:
1 |
|
Mach aber vorher ein Backup.
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.
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 .. ;-)
Ä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 ...
Weshalb wird hier soviel Wind um eine vollkommen triviale Aufgabe gemacht?
Insbesondere, wenn man bedenkt, dass die Fehlermeldung bereits vorschlägt, wie man das lösen kann. Es hätte gereicht, diesen Vorschlag per copy/paste zu übernehmen…
Klar, viele Tools sind da nicht mitgewachsen, und verstehen immer noch nur 256 lange Pfade.
Die Längenbeschränkung liegt wohl nicht bei 256, sondern lustigerweise bei 260. Wenn man mehr haben will, muss man das wohl erst explizit aktivieren: https://learn.microsoft.com/de-de/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later
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?
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.
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
NTFS ist auf 32K beschränkt. Es ist der Windows API, der Zicken macht. Mit Mechanismen wie Junctions kommt man ggf tiefer runter.
Wurde hier auf dem Arbeitsrechner (glaub Win 10) gerade erfolgreich getestet.
Ja, kann ich bestätigen. Unter Windows 10 kann man Dateien umbenennen, auch wenn sich der neue Name vom alten nur in der Groß-/Kleinschreibung unterscheiden. Mit älteren Versionen (Windows 7) hatte ich aber auch gegenteilige Erfahrungenb gemacht.
Rolf M. schrieb:
Die Längenbeschränkung liegt wohl nicht bei 256, sondern lustigerweise bei 260.
Vermutlich wegen der Extension.
Nein, es ist das "C:\" am Anfang des Pfads. Danach dürfen noch 256 Zeichen folgen, macht zusammen 260. Siehe
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.