Datei unter Linux entfernen?

[Gerald K. (geku)]

Wie kann ich unter linux die Datei mit dem Namen "-L-.-..log" entfernen?

sudo rm -L-.-..log
rm: invalid option -- 'L'                                                                          
Try 'rm ./-L-.-..log' to remove the file '-L-.-..log'.
Try 'rm --help' for more information.

[Wegstaben V. (wegstabenverbuchsler)]

Mit einer GUI Applikation die Datei umbenennen auf etwas weniger 
problematisches. Dann entfernen

[Gerald K. (geku)]

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.

[Ingo W. (uebrig)]

Probiere mal
rm "'-L-.-..log'"

gab bei mir zummindest nicht die Meldung über "ungültige Option", 
sondern "Datei nicht gefunden".

[Max H. (nilsp)]

Du schaust, welche inode die datei hat:

  ls -i

Wenn Du die inode herrausgefunden hast, dann löscht Du sie über den find 
Befehl:

  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.

[Yalu X. (yalu) (Moderator)]

Ganz einfach mit

sudo rm -- '-L-.-..log'

[(prx) A. K. (prx)]

To remove a file whose name starts with a '-', for example '-foo', use one of these commands:

rm -- -foo
rm ./-foo

[Ein T. (ein_typ)]

(prx) A. K. schrieb:
>

> To remove a file whose name starts with a '-', for example '-foo', use 
> one of these commands:
> 
> rm -- -foo
> rm ./-foo
>

;-)

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.

[(prx) A. K. (prx)]

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.

[Norbert (der_norbert)]

Yalu X. schrieb:
> Ganz einfach mit
> sudo rm -- '-L-.-..log'

Und für die ganz Ängstlichen noch in 'Interactive':

sudo rm -i -- '-L-.-..log'

[Martin H. (horo)]

Gerald K. schrieb:
> Wie kann ich unter linux die Datei mit dem Namen "-L-.-..log" entfernen?
>
>

> sudo rm -L-.-..log
> rm: invalid option -- 'L'
> Try 'rm ./-L-.-..log' to remove the file '-L-.-..log'.
> Try 'rm --help' for more information.
>

Hast Du den Vorschlag 'rm ./-L-.-..log' probiert?

[Norbert (der_norbert)]

Weshalb wird hier soviel Wind um eine vollkommen triviale Aufgabe 
gemacht?

~/tmp/x$ ls -l 
insgesamt 0
~/tmp/x$ > '-L-.-..log'
~/tmp/x$ ls -l 
insgesamt 0
-rw------- 1 norbert norbert 0 18. Mär 10:32 -L-.-..log
~/tmp/x$ rm -i -- '-L-.-..log'
rm: reguläre leere Datei '-L-.-..log' entfernen? y
~/tmp/x$ ls -l 
insgesamt 0
~/tmp/x$

[Ein T. (ein_typ)]

(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

[(prx) A. K. (prx)]

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.

[Yalu X. (yalu) (Moderator)]

(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.

[(prx) A. K. (prx)]

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.

[Ein T. (ein_typ)]

(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. ;-)

[Alexander T. (Firma: Arge f. t. abgeh. Technologie) (atat)]

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. (geku)]

Yalu X. schrieb:
> Ganz einfach mit
>
> sudo rm -- '-L-.-..log'

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.

Aber der Hinweis Try ...  half.

Danke an euch Allen.

[Norbert (der_norbert)]

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 ›--‹

[Yalu X. (yalu) (Moderator)]

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:

Entry '' in ??? (2) has a zero-length name.
Clear<y>? no
Entry '' in ??? (2) has a zero-length name.
Clear<y>? no
Directory inode 2, block #0: directory passes checks but fails checksum.
Fix<y>? yes

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.

[Norbert (der_norbert)]

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 (der_norbert)]

Mit ext2 getestet. Geht auch nichts verloren.
Hatte mich schon erschreckt! ;-)

~$ cd tmp

~/tmp$ truncate --size 1M IMAGE

~/tmp$ ls -l
    -rw------- 1 norbert norbert 1048576 18. Mär 13:45 IMAGE
    
~/tmp$ /sbin/mkfs.ext2 IMAGE 
    mke2fs 1.46.2 (28-Feb-2021)
    Geräteblöcke werden verworfen: erledigt                        
    Ein Dateisystem mit 1024 (1k) Blöcken und 128 Inodes wird erzeugt.

    beim Anfordern von Speicher für die Gruppentabellen: erledigt                        
    Inode-Tabellen werden geschrieben: erledigt                        
    Die Superblöcke und die Informationen über die Dateisystemnutzung werden
    geschrieben: erledigt

~/tmp$ su -
Passwort: 

root@Entwicklung:~# losetup -f '/tmp/norbert/IMAGE' 

root@Entwicklung:~# losetup -a
    /dev/loop1: [0038]:907 (/tmp/norbert/IMAGE)
    
root@Entwicklung:~# mount /dev/loop1 /mnt/

root@Entwicklung:~# vi /mnt/testfile
    Zeile 1
    ...
    ...
    ...
    Zeile n

root@Entwicklung:~# umount /mnt 
Abgemeldet

##### Directory Eintrag auf Länge 0 patchen #####
~/tmp$ ghex IMAGE 

~/tmp$ su -
Passwort: 

root@Entwicklung:~# mount /dev/loop1 /mnt/

root@Entwicklung:~# ls -l /mnt/
    ls: das Verzeichnis '/mnt/' wird gelesen: Eingabe-/Ausgabefehler
    insgesamt 12
    drwx------ 2 root root 12288 18. Mär 13:45 lost+found

root@Entwicklung:~# umount /mnt 

root@Entwicklung:~# e2fsck -f /tmp/norbert/IMAGE 
    e2fsck 1.46.2 (28-Feb-2021)
    Durchgang 1: Inodes, Blöcke und Größen werden geprüft
    Durchgang 2: Verzeichnisstruktur wird geprüft
    Eintrag „“ in / (2) hat einen Namen der Länge Null.
    Bereinigen<jy>? ja
    Durchgang 3: Verzeichnisverknüpfungen werden geprüft
    Durchgang 4: Referenzzähler werden überprüft
    Nicht verbundener Inode 14
    Nach /lost+found verbinden<jy>? ja
    Der Referenzzähler von Inode 14 ist 2, sollte aber 1 sein.  Reparieren<jy>? ja
    Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft

    /tmp/norbert/IMAGE: ***** DATEISYSTEM WURDE VERÄNDERT *****
    /tmp/norbert/IMAGE: 12/128 Dateien (0.0% nicht zusammenhängend), 39/1024 Blöcke

root@Entwicklung:~# mount /dev/loop1 /mnt/

root@Entwicklung:~# ls -l /mnt/.
    ./  ../ 

root@Entwicklung:~# ls -l /mnt/lost+found/
    insgesamt 1
    -rw-r----- 1 root root 28 18. Mär 13:47 '#14'

root@Entwicklung:~# cat /mnt/lost+found/#14 
Zeile 1
...
...
...
Zeile n

[Yalu X. (yalu) (Moderator)]

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:

# ls -l /mnt/test/
total 179
-rw-r--r-- 1 root root 181894 18. Mär 14:48 ''
drwx------ 2 root root   1024 18. Mär 14:38  lost+found

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.

[Norbert (der_norbert)]

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ß!

[(prx) A. K. (prx)]

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.

[Norbert (der_norbert)]

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?

[(prx) A. K. (prx)]

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:

fsutil.exe file SetCaseSensitiveInfo C:\windows\system32 enable

Mach aber vorher ein Backup.

[Norbert (der_norbert)]

(prx) A. K. schrieb:
> Mach aber vorher ein Backup.

Wouldn't touch that OS with a barge pole…

[Yalu X. (yalu) (Moderator)]

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.

[Jens G. (jensig)]

(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 ...

[Rolf M. (rmagnus)]

Norbert schrieb:
> 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…

Jens G. schrieb:
> 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

[Le X. (lex_91)]

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?

[Norbert (der_norbert)]

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.

[Daniel A. (daniel-a)]

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

[(prx) A. K. (prx)]

NTFS ist auf 32K beschränkt. Es ist der Windows API, der Zicken macht. 
Mit Mechanismen wie Junctions kommt man ggf tiefer runter.

[Yalu X. (yalu) (Moderator)]

Le X. schrieb:
> 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.

Daniel A. schrieb:
> 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

Rolf M. schrieb:
> 
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

[(prx) A. K. (prx)]

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.

[Alexander (alecxs)]

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.