info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
MC Ordnerfenster Rote ?Dateien mit Null Byte
5 views
Skip to first unread message
Kay Martinen
Dec 2, 2023, 3:30:02 PM12/2/23
to
Hallo
Ich finde keine Erklärung, HowTo oder ähnliches zu den Ordnerfenstern im
Midnight Commander und was der mit roter Farbe markiert. Daher...
Hier habe ich eine 500 GB SATA Platte die aus einem anderen (Debian) PC
kommt, dort als Datenplatte beschrieben wurde und die nun in einem
kleinen Server eingebaut ist. Das ext4 Dateisystem ist überprüft und
clean, smartctl meldet keine Fehler und ich habe sie als root gemountet.
Jetzt bin ich mit dem MC auf diese Platte, habe dort das
Datenverzeichnis aufgerufen und dort sind einige Ordner und Unterordner
mit Film und Serien-Aufnahmen (TS, MPG o.ä.). Die wollte ich davon
herunter verschieben auf eine andere Platte.
Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
nur große Dateien sondern auch DVBcut index, info.dvr o.a. kleine
Dateien - aber keine Verzeichnisse selbst.
Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
Problem.
Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
sie m.E. vom mc kopierbar ist.
Es wirkt als seien die Dateien alle intakt, nichts davon ist ein link
oder kaputter link, nur der mc zeigt/versteht irgendwas falsch.
Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
oder was sonst?
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Ich finde keine Erklärung, HowTo oder ähnliches zu den Ordnerfenstern im
Midnight Commander und was der mit roter Farbe markiert. Daher...
Hier habe ich eine 500 GB SATA Platte die aus einem anderen (Debian) PC
kommt, dort als Datenplatte beschrieben wurde und die nun in einem
kleinen Server eingebaut ist. Das ext4 Dateisystem ist überprüft und
clean, smartctl meldet keine Fehler und ich habe sie als root gemountet.
Jetzt bin ich mit dem MC auf diese Platte, habe dort das
Datenverzeichnis aufgerufen und dort sind einige Ordner und Unterordner
mit Film und Serien-Aufnahmen (TS, MPG o.ä.). Die wollte ich davon
herunter verschieben auf eine andere Platte.
Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
nur große Dateien sondern auch DVBcut index, info.dvr o.a. kleine
Dateien - aber keine Verzeichnisse selbst.
Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
Problem.
Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
sie m.E. vom mc kopierbar ist.
Es wirkt als seien die Dateien alle intakt, nichts davon ist ein link
oder kaputter link, nur der mc zeigt/versteht irgendwas falsch.
Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
oder was sonst?
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Jens Schüßler
Dec 3, 2023, 5:20:05 AM12/3/23
to
* Kay Martinen <use...@martinen.de> [02-12-23 20:22]:
Erkennung für das filehighlightng. Was passiert wenn du das mit
"Options/Panel options/File highlight" mal ausschaltest?
Die Farben hängen übrigens davon ab was du für einen Skin nutzt. Ich geh
jetzt mal von /usr/share/mc/skins/default.ini aus, da ist Grün 'media',
das würde ja passen.
>
> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
> nur große Dateien sondern auch DVBcut index, info.dvr o.a. kleine
> Dateien - aber keine Verzeichnisse selbst.
>
> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
> Problem.
>
> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
> sie m.E. vom mc kopierbar ist.
Klingt für mich danach als hätte der mc ein Problem mit der filetype
> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
> nur große Dateien sondern auch DVBcut index, info.dvr o.a. kleine
> Dateien - aber keine Verzeichnisse selbst.
>
> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
> Problem.
>
> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
> sie m.E. vom mc kopierbar ist.
Erkennung für das filehighlightng. Was passiert wenn du das mit
"Options/Panel options/File highlight" mal ausschaltest?
Die Farben hängen übrigens davon ab was du für einen Skin nutzt. Ich geh
jetzt mal von /usr/share/mc/skins/default.ini aus, da ist Grün 'media',
das würde ja passen.
Kay Martinen
Dec 3, 2023, 12:50:03 PM12/3/23
to
Am 03.12.23 um 11:05 schrieb Jens Schüßler:
Ja, der Default-Skin ist aktiv.
> da ist Grün 'media', das würde ja passen.
Die Dateien wie 'ls' sie sieht:
homes 3.4.5 # ls -al
total 2006560
drwxrwxrwx 2 root root 4096 Jul 16 2017 .
drwxr-xr-x 35 root root 4096 Feb 16 2023 ..
-rwxrwxrwx 1 root root 2053978208 Feb 15 2023 00001.ts
-rwxrwxrwx 1 root root 719616 Mar 30 2017 index
-rwxrwxrwx 1 root root 1097 Feb 15 2023 info
homes 3.4.5 # pwd
/data/Videos/Supergirl/SG - Metallo
Und was MC mir zeigt kann ich im ssh Fenster nicht copypasten und ein
Bildschirmphoto kann ich hier kaum anhängen, einen Weg aus einem Photo
wieder Text (OCR?) zu machen habe ich nicht parat, also...
Alle Namen und Zahlen sind jetzt in grau.
er zeigt die 00001.ts mit einem * davor und 1959M als Größe und
korrektem Datum.
Die index und info datein haben null byte, immer noch ein ? am anfang
und Jan 1 1970 als Datum.
Ich hab das rechte Panel mal auf info umgeschaltet da zeigt er bei der
index-datei
location 0h:0h
Node: ---------- (0000)
Attributes: ----//---e-------
(das // soll viele --- darstellen)
Links: 0
Owner: root/root
Size 0 (o Blocks)
Changed/modified/accessed sind alle Jan 1 1970
Filesystem /data
Device: /dev/sdc1
Type ext4 (821h)
Free Space 366G /457G (79%)
Free Nodes 30531403 /30531584 (99%)
Wobei mir nur die Free Nodes seltsam vorkommen. Zu voll oder?
'df -h' zeigt
/dev/sdc1 458G 92G 343G 22% /data
Wenn ich die index und info dateien ein mal mit F3 zum Betrachten
geöffnet habe und mit ESC verlasse passiert erst mal nichts in der
Anzeige des Fensters. Aber wenn ich dann zum übergeordneten Fenster
wechsele und dann wieder zurück in den Ordner, dann werden die o.g. AUCH
richtig angezeigt. Nur... was kann das auslösen?
Es funktioniert so bei jeder datei die man ein mal angesehen hat. Jede
einzeln und dann nur die im jeweiligen Ordner. Und wenn man mc beendet
und gleich wieder in dem (pwd) verzeichnis ist dann erinnert er sich
auch an diese Dateien. Nur an die.
> da ist Grün 'media', das würde ja passen.
homes 3.4.5 # ls -al
total 2006560
drwxrwxrwx 2 root root 4096 Jul 16 2017 .
drwxr-xr-x 35 root root 4096 Feb 16 2023 ..
-rwxrwxrwx 1 root root 2053978208 Feb 15 2023 00001.ts
-rwxrwxrwx 1 root root 719616 Mar 30 2017 index
-rwxrwxrwx 1 root root 1097 Feb 15 2023 info
homes 3.4.5 # pwd
/data/Videos/Supergirl/SG - Metallo
Und was MC mir zeigt kann ich im ssh Fenster nicht copypasten und ein
Bildschirmphoto kann ich hier kaum anhängen, einen Weg aus einem Photo
wieder Text (OCR?) zu machen habe ich nicht parat, also...
Alle Namen und Zahlen sind jetzt in grau.
er zeigt die 00001.ts mit einem * davor und 1959M als Größe und
korrektem Datum.
Die index und info datein haben null byte, immer noch ein ? am anfang
und Jan 1 1970 als Datum.
Ich hab das rechte Panel mal auf info umgeschaltet da zeigt er bei der
index-datei
location 0h:0h
Node: ---------- (0000)
Attributes: ----//---e-------
(das // soll viele --- darstellen)
Links: 0
Owner: root/root
Size 0 (o Blocks)
Changed/modified/accessed sind alle Jan 1 1970
Filesystem /data
Device: /dev/sdc1
Type ext4 (821h)
Free Space 366G /457G (79%)
Free Nodes 30531403 /30531584 (99%)
Wobei mir nur die Free Nodes seltsam vorkommen. Zu voll oder?
'df -h' zeigt
/dev/sdc1 458G 92G 343G 22% /data
Wenn ich die index und info dateien ein mal mit F3 zum Betrachten
geöffnet habe und mit ESC verlasse passiert erst mal nichts in der
Anzeige des Fensters. Aber wenn ich dann zum übergeordneten Fenster
wechsele und dann wieder zurück in den Ordner, dann werden die o.g. AUCH
richtig angezeigt. Nur... was kann das auslösen?
Es funktioniert so bei jeder datei die man ein mal angesehen hat. Jede
einzeln und dann nur die im jeweiligen Ordner. Und wenn man mc beendet
und gleich wieder in dem (pwd) verzeichnis ist dann erinnert er sich
auch an diese Dateien. Nur an die.
Sieghard Schicktanz
Dec 3, 2023, 4:13:06 PM12/3/23
to
Hallo Kay,
Du schriebst am Sat, 2 Dec 2023 21:22:59 +0100:
> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
D.h. er kann mit dem Verzeichniseintrag, bzw. einem Teil davon, nix
anfangen. Sowas passiert mir gelegentlich, wenn ich eine Maschine
abschalte, ohne ein von der gemountetes NFS-Filesystem zu umounten. Dann
wird wird der Mount-Point so dargestellt.
> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
Natürlich ändert ein "Rescan" nichts - die ausgewerteten Daten ändern sich
ja dadurch nicht.
Vielleicht ein ungültiges Datum - je nach Art des Filesystems ggfs. statt
amerikaischer europäische Reihenfolge (Tag<->Monat vertauscht), oder sonst
nicht auswertbar?
> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
Also eher kein Linux-Filesystem, da würde man solche Attribute
normalerewise tunlichst vermeiden. Aber Du schriebst von ext4...
Zeigt das "ls -al" korrekte Datumsangaben oder sind die "ungewöhnlich",
vielleicht sogar für "normale" Files? Wurde die Platte vor dem Ausbau
regulär umountet oder ist das System evtl. abgestürzt?
> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
> Problem.
Achso, davon kommen die Attribute... naja, wennde meinst.
> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
Und was zeigt der "mc" dann für die Kopie an Daten an? Korrekte Länge,
korrektes Datum/Uhrzeit? Und wassagr "stat" zu den Dateien, Original und
Kopie?
> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
> sie m.E. vom mc kopierbar ist.
Da der "file"-Aufruf für den "mc" vollkommen transparent ist, soweit der
nichts am Directory-Eintrag verändert, kann das nur heißen, daß dieser
halt doch nicht in Ordnung war - ggfs. Mount-Option "atime" gesetzt? Dann
ändert der Aufruf von "file" diesen Wert natürlich, und wenn der vorher
kaputt war, passt das nachher (beim automatischen "Re-Scan") wieder.
> Es wirkt als seien die Dateien alle intakt, nichts davon ist ein link
> oder kaputter link, nur der mc zeigt/versteht irgendwas falsch.
Die Dateien sind dann wohl soweit intakt, als sie für das Filesystem
konsistent sind - also mit den inodes und Directory-Einträgen
zusammenpassen. Aber zumindest die Directory-Einträge sind offenbar
"faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das mußt
Du aber für jedes File wohl oder übel einzeln prüfen...
> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
> oder was sonst?
Eher was sonst, schätze ich. Ich würde dem Filesystem nicht trauen.
(Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
_einwandfrei_ befindet... Besser noch ein scan damit.)
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Du schriebst am Sat, 2 Dec 2023 21:22:59 +0100:
> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
anfangen. Sowas passiert mir gelegentlich, wenn ich eine Maschine
abschalte, ohne ein von der gemountetes NFS-Filesystem zu umounten. Dann
wird wird der Mount-Point so dargestellt.
> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
ja dadurch nicht.
Vielleicht ein ungültiges Datum - je nach Art des Filesystems ggfs. statt
amerikaischer europäische Reihenfolge (Tag<->Monat vertauscht), oder sonst
nicht auswertbar?
> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
normalerewise tunlichst vermeiden. Aber Du schriebst von ext4...
Zeigt das "ls -al" korrekte Datumsangaben oder sind die "ungewöhnlich",
vielleicht sogar für "normale" Files? Wurde die Platte vor dem Ausbau
regulär umountet oder ist das System evtl. abgestürzt?
> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
> Problem.
> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
korrektes Datum/Uhrzeit? Und wassagr "stat" zu den Dateien, Original und
Kopie?
> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
> sie m.E. vom mc kopierbar ist.
nichts am Directory-Eintrag verändert, kann das nur heißen, daß dieser
halt doch nicht in Ordnung war - ggfs. Mount-Option "atime" gesetzt? Dann
ändert der Aufruf von "file" diesen Wert natürlich, und wenn der vorher
kaputt war, passt das nachher (beim automatischen "Re-Scan") wieder.
> Es wirkt als seien die Dateien alle intakt, nichts davon ist ein link
> oder kaputter link, nur der mc zeigt/versteht irgendwas falsch.
konsistent sind - also mit den inodes und Directory-Einträgen
zusammenpassen. Aber zumindest die Directory-Einträge sind offenbar
"faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das mußt
Du aber für jedes File wohl oder übel einzeln prüfen...
> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
> oder was sonst?
(Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
_einwandfrei_ befindet... Besser noch ein scan damit.)
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Lutz Falke
Dec 3, 2023, 4:55:11 PM12/3/23
to
Kay Martinen schrieb:
tatsächlich kaputt ist oder wenn bei Netzwerkmounts was nicht stimmt.
>>> Ein
>>> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
>>> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
>>> nur große Dateien sondern auch DVBcut index, info.dvr o.a. kleine
>>> Dateien - aber keine Verzeichnisse selbst.
Sehr seltsam.
>>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
>>> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
>>> Problem.
>>>
>>> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
>>> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
>>> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
>>> sie m.E. vom mc kopierbar ist.
>>
>> Klingt für mich danach als hätte der mc ein Problem mit der filetype
>> Erkennung für das filehighlightng. Was passiert wenn du das mit
>> "Options/Panel options/File highlight" mal ausschaltest?
Eher nicht. Die Filetype-Erkennung orientiert sich hauptsächlich am
Dateinamen und das ist ja nach Kays Beschreibung so ziemlich das
einzige, was noch halbwegs intakt ist.
>> Die Farben hängen übrigens davon ab was du für einen Skin nutzt. Ich geh
>> jetzt mal von /usr/share/mc/skins/default.ini aus,
>
> Ja, der Default-Skin ist aktiv.
>
>> da ist Grün 'media', das würde ja passen.
Grün mit * davor ist eine ausführbare Datei. Das ligt daran, dass Kay
in seinem Versuch oben das x-Bit überall gesetzt hat. Und laut
/etc/mc/filehighlight.ini
hat das Vorrang vor allem andren.
> Die Dateien wie 'ls' sie sieht:
>
> homes 3.4.5 # ls -al
> total 2006560
> drwxrwxrwx 2 root root 4096 Jul 16 2017 .
> drwxr-xr-x 35 root root 4096 Feb 16 2023 ..
> -rwxrwxrwx 1 root root 2053978208 Feb 15 2023 00001.ts
> -rwxrwxrwx 1 root root 719616 Mar 30 2017 index
> -rwxrwxrwx 1 root root 1097 Feb 15 2023 info
> homes 3.4.5 # pwd
> /data/Videos/Supergirl/SG - Metallo
>
> Und was MC mir zeigt kann ich im ssh Fenster nicht copypasten und ein
> Bildschirmphoto kann ich hier kaum anhängen, einen Weg aus einem Photo
> wieder Text (OCR?) zu machen habe ich nicht parat, also...
Du kannst mit "mc -d" den Maousupport abschalten, dann geht auch
Copy-Paste. Ich glaubs dir aber auch so. ;)
> Die index und info datein haben null byte, immer noch ein ? am anfang
> und Jan 1 1970 als Datum.
>
> Ich hab das rechte Panel mal auf info umgeschaltet da zeigt er bei der
> index-datei
>
> location 0h:0h
> Node: ---------- (0000)
> Attributes: ----//---e-------
> (das // soll viele --- darstellen)
> Links: 0
Also das ist nicht richtig. Eine existierende Datei sollte einen
Linkcount von mindestens 1 haben.
> Owner: root/root
> Size 0 (o Blocks)
> Changed/modified/accessed sind alle Jan 1 1970
> Filesystem /data
> Device: /dev/sdc1
> Type ext4 (821h)
> Free Space 366G /457G (79%)
> Free Nodes 30531403 /30531584 (99%)
>
> Wobei mir nur die Free Nodes seltsam vorkommen. Zu voll oder?
Da steht ja "Free" also sind fast alle Inodes noch frei. Auf dem
Deteisystem befinden sich demnach etwa 181 Dateien und Verzeichnisse.
> 'df -h' zeigt
>
> /dev/sdc1 458G 92G 343G 22% /data
Hast du dich da vertippt? die Differend beim freien Speicher (366G vs.
343G) kann ich mir nicht erklären. Bei mir unterscheiden sich die
Werte von mc und "df -h" nicht wesentlich.
> Wenn ich die index und info dateien ein mal mit F3 zum Betrachten
> geöffnet habe und mit ESC verlasse passiert erst mal nichts in der
> Anzeige des Fensters. Aber wenn ich dann zum übergeordneten Fenster
> wechsele und dann wieder zurück in den Ordner, dann werden die o.g. AUCH
> richtig angezeigt. Nur... was kann das auslösen?
Keine Ahnung. Ich würde mal mit strace nachsehen, was der mc da so
treibt.
Etwa so:
$ strace -o mc.log --trace=openat,lstat,getdents64 mc
Schreibt die gemachten Systemaufrue nach "mc.log". Das sind halt
ziemlich viele, deshalb erstmal auf das Wesentliche gefiltert.
Den mc direkt wieder beenden und mal ins Log schauen.
Du müsstest da in etwa den folgenden Ablauf finden:
- *openat* auf das aktuelle Verzeichnis. Rückgabewert sollte ein
Filedescriptor sein.
- *getdents64* mit dem FD (1. Parameter) zum Einlesen der Dateiliste
des Verzeichnisses.
- *lstat*-Aufrufe für die einzelnen Dateien.
Wenn hier Fehler Rückgabewerte "-1" auftreten, ist irgendwas faul.
Normalerweise müsste dann da auch der "errno" dabeistehen.
Die Ausgabe ist leider etwas lang, musst du mal etwas suchen.
> Es funktioniert so bei jeder datei die man ein mal angesehen hat. Jede
> einzeln und dann nur die im jeweiligen Ordner. Und wenn man mc beendet
> und gleich wieder in dem (pwd) verzeichnis ist dann erinnert er sich
> auch an diese Dateien. Nur an die.
Ist das Verhalten eigentlich auch über mounts hinweg reproduzierbar?
Also bleiben die betrachteten Dateien nach einem umount und erneutem
mount "geheilt" oder sind sie dann wieder "kaputt"? Hilft es auch die
Dateien außerhalb des mc zu öffnen?
Hintergrund: Beim umount wird der Cache verworfen. Vielleicht kommen
die Daten ja aus dem Cache, der mc kann sie aber selbst nicht lesen?
Kann ich mir zwar auch nicht so recht vorstellen, aber wer weiß ...
Lutz
> Am 03.12.23 um 11:05 schrieb Jens Schüßler:
>> * Kay Martinen <use...@martinen.de> [02-12-23 20:22]:
>>>
>>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>>> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts.
So ähnliche Ausgaben kenne ich sonst nur von ls, wenn das Dateisystem
>> * Kay Martinen <use...@martinen.de> [02-12-23 20:22]:
>>>
>>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>>> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts.
tatsächlich kaputt ist oder wenn bei Netzwerkmounts was nicht stimmt.
>>> Ein
>>> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
>>> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
>>> nur große Dateien sondern auch DVBcut index, info.dvr o.a. kleine
>>> Dateien - aber keine Verzeichnisse selbst.
>>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
>>> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
>>> Problem.
>>>
>>> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
>>> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
>>> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
>>> sie m.E. vom mc kopierbar ist.
>>
>> Klingt für mich danach als hätte der mc ein Problem mit der filetype
>> Erkennung für das filehighlightng. Was passiert wenn du das mit
>> "Options/Panel options/File highlight" mal ausschaltest?
Dateinamen und das ist ja nach Kays Beschreibung so ziemlich das
einzige, was noch halbwegs intakt ist.
>> Die Farben hängen übrigens davon ab was du für einen Skin nutzt. Ich geh
>> jetzt mal von /usr/share/mc/skins/default.ini aus,
>
> Ja, der Default-Skin ist aktiv.
>
>> da ist Grün 'media', das würde ja passen.
in seinem Versuch oben das x-Bit überall gesetzt hat. Und laut
/etc/mc/filehighlight.ini
hat das Vorrang vor allem andren.
> Die Dateien wie 'ls' sie sieht:
>
> homes 3.4.5 # ls -al
> total 2006560
> drwxrwxrwx 2 root root 4096 Jul 16 2017 .
> drwxr-xr-x 35 root root 4096 Feb 16 2023 ..
> -rwxrwxrwx 1 root root 2053978208 Feb 15 2023 00001.ts
> -rwxrwxrwx 1 root root 719616 Mar 30 2017 index
> -rwxrwxrwx 1 root root 1097 Feb 15 2023 info
> homes 3.4.5 # pwd
> /data/Videos/Supergirl/SG - Metallo
>
> Und was MC mir zeigt kann ich im ssh Fenster nicht copypasten und ein
> Bildschirmphoto kann ich hier kaum anhängen, einen Weg aus einem Photo
> wieder Text (OCR?) zu machen habe ich nicht parat, also...
Copy-Paste. Ich glaubs dir aber auch so. ;)
>
> Alle Namen und Zahlen sind jetzt in grau.
>
> er zeigt die 00001.ts mit einem * davor und 1959M als Größe und
> korrektem Datum.
Wegen dem x-Bit. Siehe oben.
> Alle Namen und Zahlen sind jetzt in grau.
>
> er zeigt die 00001.ts mit einem * davor und 1959M als Größe und
> korrektem Datum.
> Die index und info datein haben null byte, immer noch ein ? am anfang
> und Jan 1 1970 als Datum.
>
> Ich hab das rechte Panel mal auf info umgeschaltet da zeigt er bei der
> index-datei
>
> location 0h:0h
> Node: ---------- (0000)
> Attributes: ----//---e-------
> (das // soll viele --- darstellen)
> Links: 0
Linkcount von mindestens 1 haben.
> Owner: root/root
> Size 0 (o Blocks)
> Changed/modified/accessed sind alle Jan 1 1970
> Filesystem /data
> Device: /dev/sdc1
> Type ext4 (821h)
> Free Space 366G /457G (79%)
> Free Nodes 30531403 /30531584 (99%)
>
> Wobei mir nur die Free Nodes seltsam vorkommen. Zu voll oder?
Deteisystem befinden sich demnach etwa 181 Dateien und Verzeichnisse.
> 'df -h' zeigt
>
> /dev/sdc1 458G 92G 343G 22% /data
343G) kann ich mir nicht erklären. Bei mir unterscheiden sich die
Werte von mc und "df -h" nicht wesentlich.
> Wenn ich die index und info dateien ein mal mit F3 zum Betrachten
> geöffnet habe und mit ESC verlasse passiert erst mal nichts in der
> Anzeige des Fensters. Aber wenn ich dann zum übergeordneten Fenster
> wechsele und dann wieder zurück in den Ordner, dann werden die o.g. AUCH
> richtig angezeigt. Nur... was kann das auslösen?
treibt.
Etwa so:
$ strace -o mc.log --trace=openat,lstat,getdents64 mc
Schreibt die gemachten Systemaufrue nach "mc.log". Das sind halt
ziemlich viele, deshalb erstmal auf das Wesentliche gefiltert.
Den mc direkt wieder beenden und mal ins Log schauen.
Du müsstest da in etwa den folgenden Ablauf finden:
- *openat* auf das aktuelle Verzeichnis. Rückgabewert sollte ein
Filedescriptor sein.
- *getdents64* mit dem FD (1. Parameter) zum Einlesen der Dateiliste
des Verzeichnisses.
- *lstat*-Aufrufe für die einzelnen Dateien.
Wenn hier Fehler Rückgabewerte "-1" auftreten, ist irgendwas faul.
Normalerweise müsste dann da auch der "errno" dabeistehen.
Die Ausgabe ist leider etwas lang, musst du mal etwas suchen.
> Es funktioniert so bei jeder datei die man ein mal angesehen hat. Jede
> einzeln und dann nur die im jeweiligen Ordner. Und wenn man mc beendet
> und gleich wieder in dem (pwd) verzeichnis ist dann erinnert er sich
> auch an diese Dateien. Nur an die.
Also bleiben die betrachteten Dateien nach einem umount und erneutem
mount "geheilt" oder sind sie dann wieder "kaputt"? Hilft es auch die
Dateien außerhalb des mc zu öffnen?
Hintergrund: Beim umount wird der Cache verworfen. Vielleicht kommen
die Daten ja aus dem Cache, der mc kann sie aber selbst nicht lesen?
Kann ich mir zwar auch nicht so recht vorstellen, aber wer weiß ...
Lutz
Kay Martinen
Dec 3, 2023, 5:20:03 PM12/3/23
to
Am 03.12.23 um 21:10 schrieb Sieghard Schicktanz:
aufgerufen, als root.
>> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
>
> Natürlich ändert ein "Rescan" nichts - die ausgewerteten Daten ändern sich
> ja dadurch nicht.
Ich meinte das 'rescan' das mc im Menü des Ordner-panels anbietet. Ich
denke der liest dabei nur den ordner neu ein.
> Vielleicht ein ungültiges Datum - je nach Art des Filesystems ggfs. statt
> amerikaischer europäische Reihenfolge (Tag<->Monat vertauscht), oder sonst
> nicht auswertbar?
Glaube ich nicht da NUR mc das nicht richtig anzeigt. Direkt in der
shell oder in der shell die mc unter den panels laufen hat (mit
Control-O zu erreichen) wird es ja richtig angezeigt. Oder, was ich für
richtig hielte!
>
>> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
>> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
>
> Also eher kein Linux-Filesystem, da würde man solche Attribute
> normalerewise tunlichst vermeiden. Aber Du schriebst von ext4...
Die sind nur zw. Erleichterung dort gesetzt da dies eine reine
Datenplatte ist und sein soll. Die dort sind sollen auch runter. Aber
möglichst nicht alle einzeln! Und es IST ein Linux. Hatte ich im OP auch
geschrieben.
> Zeigt das "ls -al" korrekte Datumsangaben oder sind die "ungewöhnlich",
> vielleicht sogar für "normale" Files? Wurde die Platte vor dem Ausbau
> regulär umountet oder ist das System evtl. abgestürzt?
Nein, da war nichts abgestürzt und wurde auch korrekt unmountet vor dem
ausbau. Zudem hab ich vor dem mounten in diesem Server ein fsck gemacht
der keine Fehler meldete.
>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
>> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
>> Problem.
>
> Achso, davon kommen die Attribute... naja, wennde meinst.
Das war nur der Versuch sicher zu stellen das ich als root auch an alle
dateien ran komme. Nicht das irgendwelche andere Rechte oder besitzter
hätten und das die Probleme erklärte. Tut's offenbar nicht.
>> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
>
> Und was zeigt der "mc" dann für die Kopie an Daten an? Korrekte Länge,
> korrektes Datum/Uhrzeit? Und wassagr "stat" zu den Dateien, Original und
> Kopie?
Das ist ein Punkt. Wenn ich versuche mit mc so eine rote datei zu
kopieren oder verschieben dann meldet mc "could not stat file ..."
Den Punkt hab ich im OP leider vergessen zu erwähnen.
>> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
>> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
>> sie m.E. vom mc kopierbar ist.
>
> Da der "file"-Aufruf für den "mc" vollkommen transparent ist, soweit der
> nichts am Directory-Eintrag verändert, kann das nur heißen, daß dieser
> halt doch nicht in Ordnung war - ggfs. Mount-Option "atime" gesetzt?
aus der fstab:
/dev/sdc1 on /data type ext4 (rw,relatime,errors=remount-ro)
> Dann
> ändert der Aufruf von "file" diesen Wert natürlich, und wenn der vorher
> kaputt war, passt das nachher (beim automatischen "Re-Scan") wieder.
Naja, wie ich im nebenpost schon schrieb: 'file datei' und dann ein
verzeichnis hoch und wieder zurück und dann merkt mc sich die korrekten
werte der datei. Auch nachdem man ihn beendete und gleich neu startet in
dem verzeichnis.
>> Es wirkt als seien die Dateien alle intakt, nichts davon ist ein link
>> oder kaputter link, nur der mc zeigt/versteht irgendwas falsch.
>
> Die Dateien sind dann wohl soweit intakt, als sie für das Filesystem
> konsistent sind - also mit den inodes und Directory-Einträgen
> zusammenpassen. Aber zumindest die Directory-Einträge sind offenbar
> "faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das mußt
> Du aber für jedes File wohl oder übel einzeln prüfen...
Testdisk? oder was würdest du vorschlagen?
>> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
>> oder was sonst?
>
> Eher was sonst, schätze ich. Ich würde dem Filesystem nicht trauen.
> (Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
> _einwandfrei_ befindet... Besser noch ein scan damit.)
Tut er. Insgesamt PASSED. Öhm, nur ein paar Details die ich auch grad
entdeckte...
Siehe 1, 7 und 195 bei denen mir nicht klar ist ob die am Alter liegen
und evtl. früher schon oder aktuell auftraten.
smartctl 7.4 2023-08-01 r5530 [i686-linux-5.15.137-eisfair-1-SMP] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST500DM002-1BD142
Serial Number: Z3TSJMWH
LU WWN Device Id: 5 000c50 0651caf08
Firmware Version: KC47
User Capacity: 500,107,862,016 bytes [500 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Device is: In smartctl database 7.3/5533
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is: Sun Dec 3 23:07:16 2023 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection:
Enabled.
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test
has ever
been run.
Total time to complete Offline
data collection: ( 592) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection
on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 78) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control
supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail
Always - 198913968
3 Spin_Up_Time 0x0003 100 098 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 270
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail
Always - 44846041
9 Power_On_Hours 0x0032 091 091 000 Old_age
Always - 8015
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 159
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always
- 0
184 End-to-End_Error 0x0032 100 100 099 Old_age Always
- 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always
- 0
188 Command_Timeout 0x0032 100 100 000 Old_age Always
- 0 0 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always
- 0
190 Airflow_Temperature_Cel 0x0022 067 058 045 Old_age Always
- 33 (Min/Max 25/35)
194 Temperature_Celsius 0x0022 033 042 000 Old_age Always
- 33 (0 18 0 0 0)
195 Hardware_ECC_Recovered 0x001a 046 030 000 Old_age Always
- 198913968
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always
- 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always
- 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age
Offline - 8006h+20m+32.974s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age
Offline - 499644052
242 Total_LBAs_Read 0x0000 100 253 000 Old_age
Offline - 3038948290
SMART Error Log Version: 1
ATA Error Count: 1
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 1 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
08 51 00 00 00 00 00 Error:
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
3f 00 01 ff ff ff 4f 00 00:00:11.037 WRITE LOG EXT
2f 00 02 ff ff ff 4f 00 00:00:11.037 READ LOG EXT
3f 00 01 ff ff ff 4f 00 00:00:11.036 WRITE LOG EXT
2f 00 02 ff ff ff 4f 00 00:00:11.035 READ LOG EXT
3f 00 01 ff ff ff 4f 00 00:00:11.035 WRITE LOG EXT
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 8015
-
# 2 Extended offline Completed without error 00% 7972
-
# 3 Short offline Completed without error 00% 7970
-
# 4 Short offline Completed without error 00% 7946
-
# 5 Short offline Completed without error 00% 7922
-
# 6 Short offline Completed without error 00% 7910
-
# 7 Short offline Completed without error 00% 7897
-
# 8 Short offline Completed without error 00% 1905
-
# 9 Short offline Completed without error 00% 0
-
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
The above only provides legacy SMART information - try 'smartctl -x' for
more
> Hallo Kay,
>
> Du schriebst am Sat, 2 Dec 2023 21:22:59 +0100:
>
>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>
> D.h. er kann mit dem Verzeichniseintrag, bzw. einem Teil davon, nix
> anfangen. Sowas passiert mir gelegentlich, wenn ich eine Maschine
> abschalte, ohne ein von der gemountetes NFS-Filesystem zu umounten. Dann
> wird wird der Mount-Point so dargestellt.
Das ist allerdings ein lokales Dateisystem und der mc wird auch lokal
>
> Du schriebst am Sat, 2 Dec 2023 21:22:59 +0100:
>
>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>
> D.h. er kann mit dem Verzeichniseintrag, bzw. einem Teil davon, nix
> anfangen. Sowas passiert mir gelegentlich, wenn ich eine Maschine
> abschalte, ohne ein von der gemountetes NFS-Filesystem zu umounten. Dann
> wird wird der Mount-Point so dargestellt.
aufgerufen, als root.
>> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts. Ein
>
> Natürlich ändert ein "Rescan" nichts - die ausgewerteten Daten ändern sich
> ja dadurch nicht.
denke der liest dabei nur den ordner neu ein.
> Vielleicht ein ungültiges Datum - je nach Art des Filesystems ggfs. statt
> amerikaischer europäische Reihenfolge (Tag<->Monat vertauscht), oder sonst
> nicht auswertbar?
shell oder in der shell die mc unter den panels laufen hat (mit
Control-O zu erreichen) wird es ja richtig angezeigt. Oder, was ich für
richtig hielte!
>
>> 'ls -al' zeigt aber in jedem dieser Verzeichnisse korrekte dateigrößen,
>> attribute (0777) und besitzer (root:root) an. Betroffen sind aber nicht
>
> Also eher kein Linux-Filesystem, da würde man solche Attribute
> normalerewise tunlichst vermeiden. Aber Du schriebst von ext4...
Datenplatte ist und sein soll. Die dort sind sollen auch runter. Aber
möglichst nicht alle einzeln! Und es IST ein Linux. Hatte ich im OP auch
geschrieben.
> Zeigt das "ls -al" korrekte Datumsangaben oder sind die "ungewöhnlich",
> vielleicht sogar für "normale" Files? Wurde die Platte vor dem Ausbau
> regulär umountet oder ist das System evtl. abgestürzt?
ausbau. Zudem hab ich vor dem mounten in diesem Server ein fsck gemacht
der keine Fehler meldete.
>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
>> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
>> Problem.
>
> Achso, davon kommen die Attribute... naja, wennde meinst.
dateien ran komme. Nicht das irgendwelche andere Rechte oder besitzter
hätten und das die Probleme erklärte. Tut's offenbar nicht.
>> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
>
> Und was zeigt der "mc" dann für die Kopie an Daten an? Korrekte Länge,
> korrektes Datum/Uhrzeit? Und wassagr "stat" zu den Dateien, Original und
> Kopie?
kopieren oder verschieben dann meldet mc "could not stat file ..."
Den Punkt hab ich im OP leider vergessen zu erwähnen.
>> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
>> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
>> sie m.E. vom mc kopierbar ist.
>
> Da der "file"-Aufruf für den "mc" vollkommen transparent ist, soweit der
> nichts am Directory-Eintrag verändert, kann das nur heißen, daß dieser
> halt doch nicht in Ordnung war - ggfs. Mount-Option "atime" gesetzt?
/dev/sdc1 on /data type ext4 (rw,relatime,errors=remount-ro)
> Dann
> ändert der Aufruf von "file" diesen Wert natürlich, und wenn der vorher
> kaputt war, passt das nachher (beim automatischen "Re-Scan") wieder.
verzeichnis hoch und wieder zurück und dann merkt mc sich die korrekten
werte der datei. Auch nachdem man ihn beendete und gleich neu startet in
dem verzeichnis.
>> Es wirkt als seien die Dateien alle intakt, nichts davon ist ein link
>> oder kaputter link, nur der mc zeigt/versteht irgendwas falsch.
>
> Die Dateien sind dann wohl soweit intakt, als sie für das Filesystem
> konsistent sind - also mit den inodes und Directory-Einträgen
> zusammenpassen. Aber zumindest die Directory-Einträge sind offenbar
> "faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das mußt
> Du aber für jedes File wohl oder übel einzeln prüfen...
>> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
>> oder was sonst?
>
> Eher was sonst, schätze ich. Ich würde dem Filesystem nicht trauen.
> (Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
> _einwandfrei_ befindet... Besser noch ein scan damit.)
entdeckte...
Siehe 1, 7 und 195 bei denen mir nicht klar ist ob die am Alter liegen
und evtl. früher schon oder aktuell auftraten.
smartctl 7.4 2023-08-01 r5530 [i686-linux-5.15.137-eisfair-1-SMP] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST500DM002-1BD142
Serial Number: Z3TSJMWH
LU WWN Device Id: 5 000c50 0651caf08
Firmware Version: KC47
User Capacity: 500,107,862,016 bytes [500 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Device is: In smartctl database 7.3/5533
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is: Sun Dec 3 23:07:16 2023 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection:
Enabled.
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test
has ever
been run.
Total time to complete Offline
data collection: ( 592) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection
on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 78) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control
supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail
Always - 198913968
3 Spin_Up_Time 0x0003 100 098 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 270
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail
Always - 44846041
9 Power_On_Hours 0x0032 091 091 000 Old_age
Always - 8015
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 159
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always
- 0
184 End-to-End_Error 0x0032 100 100 099 Old_age Always
- 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always
- 0
188 Command_Timeout 0x0032 100 100 000 Old_age Always
- 0 0 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always
- 0
190 Airflow_Temperature_Cel 0x0022 067 058 045 Old_age Always
- 33 (Min/Max 25/35)
194 Temperature_Celsius 0x0022 033 042 000 Old_age Always
- 33 (0 18 0 0 0)
195 Hardware_ECC_Recovered 0x001a 046 030 000 Old_age Always
- 198913968
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always
- 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always
- 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age
Offline - 8006h+20m+32.974s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age
Offline - 499644052
242 Total_LBAs_Read 0x0000 100 253 000 Old_age
Offline - 3038948290
SMART Error Log Version: 1
ATA Error Count: 1
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 1 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
08 51 00 00 00 00 00 Error:
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
3f 00 01 ff ff ff 4f 00 00:00:11.037 WRITE LOG EXT
2f 00 02 ff ff ff 4f 00 00:00:11.037 READ LOG EXT
3f 00 01 ff ff ff 4f 00 00:00:11.036 WRITE LOG EXT
2f 00 02 ff ff ff 4f 00 00:00:11.035 READ LOG EXT
3f 00 01 ff ff ff 4f 00 00:00:11.035 WRITE LOG EXT
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 8015
-
# 2 Extended offline Completed without error 00% 7972
-
# 3 Short offline Completed without error 00% 7970
-
# 4 Short offline Completed without error 00% 7946
-
# 5 Short offline Completed without error 00% 7922
-
# 6 Short offline Completed without error 00% 7910
-
# 7 Short offline Completed without error 00% 7897
-
# 8 Short offline Completed without error 00% 1905
-
# 9 Short offline Completed without error 00% 0
-
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
The above only provides legacy SMART information - try 'smartctl -x' for
more
Jan Novak
Dec 4, 2023, 2:31:57 AM12/4/23
to
Am 02.12.23 um 21:22 schrieb Kay Martinen:
hängt, oder etwas ganz anderes ist, kann ich nicht sagen.
Irgendein (nicht dokumentierter) Hokey, den unabsichtlich gedrückt habe,
hat Zeilen im Editor Rot markiert. Egal was ich dann versucht habe, die
Zeile blieb für _immer_ rot ;-)
Selbst die Datei löschen und unter gleichen Namen neu anlegen half nichts.
Er speichert irgendwo Infos zu dem Eintrag. Vielleicht ist das auch bei
deinen Verzeichnissen so.
Jan
> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
> und Datum 1970.
Ich hatte mal ein ähnliches Problem mit dem Editor. Ob' damit zusammen
> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
> und Datum 1970.
hängt, oder etwas ganz anderes ist, kann ich nicht sagen.
Irgendein (nicht dokumentierter) Hokey, den unabsichtlich gedrückt habe,
hat Zeilen im Editor Rot markiert. Egal was ich dann versucht habe, die
Zeile blieb für _immer_ rot ;-)
Selbst die Datei löschen und unter gleichen Namen neu anlegen half nichts.
Er speichert irgendwo Infos zu dem Eintrag. Vielleicht ist das auch bei
deinen Verzeichnissen so.
Jan
Kay Martinen
Dec 4, 2023, 3:30:03 AM12/4/23
to
Am 04.12.23 um 08:31 schrieb Jan Novak:
Beiden Ordnerfenster des MC.
> Irgendein (nicht dokumentierter) Hokey, den unabsichtlich gedrückt habe,
> hat Zeilen im Editor Rot markiert. Egal was ich dann versucht habe, die
> Zeile blieb für _immer_ rot ;-)
> Selbst die Datei löschen und unter gleichen Namen neu anlegen half nichts.
> Er speichert irgendwo Infos zu dem Eintrag. Vielleicht ist das auch bei
> deinen Verzeichnissen so.
Das öffnen mit F3 "behebt" hier das rot auf geradezu magische weise.
Wenn man aus dem Verzeichnis raus und wieder rein geht. Dann aber bleibt
es auch so - richtig angezeigt.
> Am 02.12.23 um 21:22 schrieb Kay Martinen:
>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>> und Datum 1970.
>
> Ich hatte mal ein ähnliches Problem mit dem Editor. Ob' damit zusammen
> hängt, oder etwas ganz anderes ist, kann ich nicht sagen.
Unwarscheinlich, da es hier nicht um den MCEDIT geht sondern um die
>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>> und Datum 1970.
>
> Ich hatte mal ein ähnliches Problem mit dem Editor. Ob' damit zusammen
> hängt, oder etwas ganz anderes ist, kann ich nicht sagen.
Beiden Ordnerfenster des MC.
> Irgendein (nicht dokumentierter) Hokey, den unabsichtlich gedrückt habe,
> hat Zeilen im Editor Rot markiert. Egal was ich dann versucht habe, die
> Zeile blieb für _immer_ rot ;-)
> Selbst die Datei löschen und unter gleichen Namen neu anlegen half nichts.
> Er speichert irgendwo Infos zu dem Eintrag. Vielleicht ist das auch bei
> deinen Verzeichnissen so.
Wenn man aus dem Verzeichnis raus und wieder rein geht. Dann aber bleibt
es auch so - richtig angezeigt.
Jens Schüßler
Dec 4, 2023, 4:40:04 AM12/4/23
to
* Lutz Falke <lutz...@gmx.de> [03-12-23 21:55]:
Dateisystem einen Schlag hatte, bzw. wie sich später herausstellte die Platte.
lassen, das wird hier auch in grün angezeigt.
doch
auf 777 und root setzt ist mir auch ein Rätsel.
Jens
> Kay Martinen schrieb:
>> Am 03.12.23 um 11:05 schrieb Jens Schüßler:
>>> * Kay Martinen <use...@martinen.de> [02-12-23 20:22]:
>>>>
>>>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>>>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>>>> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts.
>
> So ähnliche Ausgaben kenne ich sonst nur von ls, wenn das Dateisystem
> tatsächlich kaputt ist oder wenn bei Netzwerkmounts was nicht stimmt.
So kenne ich das auch von einem ehemaligen Mediaplayer hier, dessen
>> Am 03.12.23 um 11:05 schrieb Jens Schüßler:
>>> * Kay Martinen <use...@martinen.de> [02-12-23 20:22]:
>>>>
>>>> Jetzt zeigt MC dort einige aber nicht alle Dateien in Rot an mit einem
>>>> vorgesetzten ? (also '?000.ts' statt 000.ts') und mit der länge 0 Byte
>>>> und Datum 1970. Ein Rescan des Ordnerfensters ändert daran nichts.
>
> So ähnliche Ausgaben kenne ich sonst nur von ls, wenn das Dateisystem
> tatsächlich kaputt ist oder wenn bei Netzwerkmounts was nicht stimmt.
Dateisystem einen Schlag hatte, bzw. wie sich später herausstellte die Platte.
>>>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle dateien
>>>> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
>>>> Problem.
>>>>
>>>> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
>>>> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
>>>> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
>>>> sie m.E. vom mc kopierbar ist.
>>>
>>> Klingt für mich danach als hätte der mc ein Problem mit der filetype
>>> Erkennung für das filehighlightng. Was passiert wenn du das mit
>>> "Options/Panel options/File highlight" mal ausschaltest?
>
> Eher nicht. Die Filetype-Erkennung orientiert sich hauptsächlich am
> Dateinamen und das ist ja nach Kays Beschreibung so ziemlich das
> einzige, was noch halbwegs intakt ist.
Wahrscheinlich hast du recht, ich hab mich von dem *.ts, täuschen
>>>> auf 0777 und root:root zu setzen aber das änderte auch nichts an dem
>>>> Problem.
>>>>
>>>> Ein versuch so eine datei mit 'cp' zu kopieren ging auch. Und bei einer
>>>> die er vorher rot und falsch anzeigte half ein 'file 000.ts' in der mc
>>>> shell das sie urplötzlich im gleichen Fenster grün angezeigt wird. Womit
>>>> sie m.E. vom mc kopierbar ist.
>>>
>>> Klingt für mich danach als hätte der mc ein Problem mit der filetype
>>> Erkennung für das filehighlightng. Was passiert wenn du das mit
>>> "Options/Panel options/File highlight" mal ausschaltest?
>
> Eher nicht. Die Filetype-Erkennung orientiert sich hauptsächlich am
> Dateinamen und das ist ja nach Kays Beschreibung so ziemlich das
> einzige, was noch halbwegs intakt ist.
lassen, das wird hier auch in grün angezeigt.
>
>>> Die Farben hängen übrigens davon ab was du für einen Skin nutzt. Ich geh
>>> jetzt mal von /usr/share/mc/skins/default.ini aus,
>>
>> Ja, der Default-Skin ist aktiv.
>>
>>> da ist Grün 'media', das würde ja passen.
>
> Grün mit * davor ist eine ausführbare Datei. Das ligt daran, dass Kay
> in seinem Versuch oben das x-Bit überall gesetzt hat. Und laut
Demnach müßten aber *alle* Dateien bei ihm grün sein, hat er
>>> Die Farben hängen übrigens davon ab was du für einen Skin nutzt. Ich geh
>>> jetzt mal von /usr/share/mc/skins/default.ini aus,
>>
>> Ja, der Default-Skin ist aktiv.
>>
>>> da ist Grün 'media', das würde ja passen.
>
> Grün mit * davor ist eine ausführbare Datei. Das ligt daran, dass Kay
> in seinem Versuch oben das x-Bit überall gesetzt hat. Und laut
doch
>>>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle
>>>> dateien auf 0777 und root:root zu setzen aber das änderte auch nichts
>>>> an dem Problem.
Werden sie aber anscheinend nicht. Warum er die Videodateien aber alle
>>>> dateien auf 0777 und root:root zu setzen aber das änderte auch nichts
>>>> an dem Problem.
auf 777 und root setzt ist mir auch ein Rätsel.
Jens
Lutz Falke
Dec 4, 2023, 6:14:01 AM12/4/23
to
Kay Martinen schrieb:
weißt du? Sonst prüft der nur, ob das Journal sauber ist. Wenn ja,
ist er fertig. Wenn man wie Sieghard Fehler in den Strukturen des FS
vermutet, muss man mal alles prüfen. Ist da dann immernoch alles
fehlerfrei?
>> Die Dateien sind dann wohl soweit intakt, als sie für das Filesystem
>> konsistent sind - also mit den inodes und Directory-Einträgen
>> zusammenpassen. Aber zumindest die Directory-Einträge sind offenbar
>> "faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das mußt
>> Du aber für jedes File wohl oder übel einzeln prüfen...
>
> Testdisk? oder was würdest du vorschlagen?
Erstmal vollständiges fsck, falls noch nicht passiert.
>>> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
>>> oder was sonst?
>>
>> Eher was sonst, schätze ich. Ich würde dem Filesystem nicht trauen.
>> (Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
>> _einwandfrei_ befindet... Besser noch ein scan damit.)
>
> Tut er. Insgesamt PASSED. Öhm, nur ein paar Details die ich auch grad
> entdeckte...
>
> Siehe 1, 7 und 195 bei denen mir nicht klar ist ob die am Alter liegen
> und evtl. früher schon oder aktuell auftraten.
>
> smartctl 7.4 2023-08-01 r5530 [i686-linux-5.15.137-eisfair-1-SMP] (SUSE RPM)
> Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
>
>=== START OF INFORMATION SECTION ===
> Model Family: Seagate Barracuda 7200.14 (AF)
> Device Model: ST500DM002-1BD142
> [...]
dir nur Seagate sagen. Es ist jedenfalls auch bei neuel Platten
normall, dass die Werte nicht 0 sind. Solange die VALUE-Spalte noch
oberhalb von THRESH liegt, sieht das die Firmware jedenfalls noch als
OK an.
Lutz
> Am 03.12.23 um 21:10 schrieb Sieghard Schicktanz:
>> Zeigt das "ls -al" korrekte Datumsangaben oder sind die "ungewöhnlich",
>> vielleicht sogar für "normale" Files? Wurde die Platte vor dem Ausbau
>> regulär umountet oder ist das System evtl. abgestürzt?
>
> Nein, da war nichts abgestürzt und wurde auch korrekt unmountet vor dem
> ausbau. Zudem hab ich vor dem mounten in diesem Server ein fsck gemacht
> der keine Fehler meldete.
Dass du bei ext3/4 das fsck mit dem Parameter "-f" aufrufen musst
>> vielleicht sogar für "normale" Files? Wurde die Platte vor dem Ausbau
>> regulär umountet oder ist das System evtl. abgestürzt?
>
> Nein, da war nichts abgestürzt und wurde auch korrekt unmountet vor dem
> ausbau. Zudem hab ich vor dem mounten in diesem Server ein fsck gemacht
> der keine Fehler meldete.
weißt du? Sonst prüft der nur, ob das Journal sauber ist. Wenn ja,
ist er fertig. Wenn man wie Sieghard Fehler in den Strukturen des FS
vermutet, muss man mal alles prüfen. Ist da dann immernoch alles
fehlerfrei?
>> Die Dateien sind dann wohl soweit intakt, als sie für das Filesystem
>> konsistent sind - also mit den inodes und Directory-Einträgen
>> zusammenpassen. Aber zumindest die Directory-Einträge sind offenbar
>> "faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das mußt
>> Du aber für jedes File wohl oder übel einzeln prüfen...
>
> Testdisk? oder was würdest du vorschlagen?
>>> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
>>> oder was sonst?
>>
>> Eher was sonst, schätze ich. Ich würde dem Filesystem nicht trauen.
>> (Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
>> _einwandfrei_ befindet... Besser noch ein scan damit.)
>
> Tut er. Insgesamt PASSED. Öhm, nur ein paar Details die ich auch grad
> entdeckte...
>
> Siehe 1, 7 und 195 bei denen mir nicht klar ist ob die am Alter liegen
> und evtl. früher schon oder aktuell auftraten.
>
> smartctl 7.4 2023-08-01 r5530 [i686-linux-5.15.137-eisfair-1-SMP] (SUSE RPM)
> Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
>
>=== START OF INFORMATION SECTION ===
> Model Family: Seagate Barracuda 7200.14 (AF)
> Device Model: ST500DM002-1BD142
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always - 198913968
> [...]
> 1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always - 198913968
> 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 44846041
> [...]
> 195 Hardware_ECC_Recovered 0x001a 046 030 000 Old_age Always - 198913968
Die RAW_VALUES sind herstellerspezifisch. Was die genau bedeuten, kann
dir nur Seagate sagen. Es ist jedenfalls auch bei neuel Platten
normall, dass die Werte nicht 0 sind. Solange die VALUE-Spalte noch
oberhalb von THRESH liegt, sieht das die Firmware jedenfalls noch als
OK an.
Lutz
Christian Garbs
Dec 4, 2023, 12:33:16 PM12/4/23
to
Mahlzeit!
Kay Martinen <use...@martinen.de> wrote:
> Und was MC mir zeigt kann ich im ssh Fenster nicht copypasten und ein
> Bildschirmphoto kann ich hier kaum anhängen, einen Weg aus einem Photo
> wieder Text (OCR?) zu machen habe ich nicht parat, also...
Du kannst Shift drücken, während Du mit der Maus hantierst, dann
funktioniert die Zwischenablage wieder. Das funktioniert auch bei
anderen Textmodus-Anwendungen, die eine Mausbedienung unterstützen
(z.B. vi oder emacs).
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Emergency repair procedure #1: Kick it.
Kay Martinen <use...@martinen.de> wrote:
> Und was MC mir zeigt kann ich im ssh Fenster nicht copypasten und ein
> Bildschirmphoto kann ich hier kaum anhängen, einen Weg aus einem Photo
> wieder Text (OCR?) zu machen habe ich nicht parat, also...
funktioniert die Zwischenablage wieder. Das funktioniert auch bei
anderen Textmodus-Anwendungen, die eine Mausbedienung unterstützen
(z.B. vi oder emacs).
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Emergency repair procedure #1: Kick it.
Sieghard Schicktanz
Dec 4, 2023, 4:13:07 PM12/4/23
to
Hallo Kay,
Du schriebst am Sun, 3 Dec 2023 18:48:53 +0100:
> Ich hab das rechte Panel mal auf info umgeschaltet da zeigt er bei der
> index-datei
>
> location 0h:0h
Das kann schon nicht sein - die Datei liegt sicher nicht am Anfang der
Platte.
> Node: ---------- (0000)
Auch falsch
> Attributes: ----//---e-------
> (das // soll viele --- darstellen)
> Links: 0
Noch was "unmögliches"
...
das wenigste zu sagen.
Das führt mich doch wieder zu der Frage: _was für ein Dateisystem ist das_?
Ja, Du schriebst "ext4" - aber kann das nicht auch ein ext3 oder 2 sein?
Oder "nur" ein ((ur-) alte Version vom ext4? Da hat's ja auch ein paar
Verbesserungen gegeben, und ggfs. ist da einfach was inkonsistent geworden,
was aber Dein "mount" nicht erkannt hat.
BTW, Du hast das doch nicht einfach per "mount -t ext4 ..." gemountet?
> Wenn ich die index und info dateien ein mal mit F3 zum Betrachten
> geöffnet habe und mit ESC verlasse passiert erst mal nichts in der
> Anzeige des Fensters. Aber wenn ich dann zum übergeordneten Fenster
> wechsele und dann wieder zurück in den Ordner, dann werden die o.g. AUCH
> richtig angezeigt. Nur... was kann das auslösen?
Dasselbe wie beim Begutachten per "file" - die atime wird neu gesetzt, was
halt bedeutet, daß der gesamte Directory-Eintrag neu geschrieben wird, und
dann mit den Daten, die beim Öffnen ggfs. "repariert" worden sind.
> Es funktioniert so bei jeder datei die man ein mal angesehen hat. Jede
> einzeln und dann nur die im jeweiligen Ordner. Und wenn man mc beendet
> und gleich wieder in dem (pwd) verzeichnis ist dann erinnert er sich
> auch an diese Dateien. Nur an die.
Da ist mir aber unklar, was Du mit "erinnert er sich" meinst - was zeigt er
denn dann an? Dasselbe wie zuvor, dasselbe wie vor dem "Ansehen", oder was?
Du schriebst am Sun, 3 Dec 2023 18:48:53 +0100:
> Ich hab das rechte Panel mal auf info umgeschaltet da zeigt er bei der
> index-datei
>
> location 0h:0h
Platte.
> Node: ---------- (0000)
Auch falsch
> Attributes: ----//---e-------
> (das // soll viele --- darstellen)
> Links: 0
...
> Free Nodes 30531403 /30531584 (99%)
>
> Wobei mir nur die Free Nodes seltsam vorkommen. Zu voll oder?
_Free_ heißt _frei_, also das Gegenteil, reichlich leer. _Das_ hat da aber
>
> Wobei mir nur die Free Nodes seltsam vorkommen. Zu voll oder?
das wenigste zu sagen.
Das führt mich doch wieder zu der Frage: _was für ein Dateisystem ist das_?
Ja, Du schriebst "ext4" - aber kann das nicht auch ein ext3 oder 2 sein?
Oder "nur" ein ((ur-) alte Version vom ext4? Da hat's ja auch ein paar
Verbesserungen gegeben, und ggfs. ist da einfach was inkonsistent geworden,
was aber Dein "mount" nicht erkannt hat.
BTW, Du hast das doch nicht einfach per "mount -t ext4 ..." gemountet?
> Wenn ich die index und info dateien ein mal mit F3 zum Betrachten
> geöffnet habe und mit ESC verlasse passiert erst mal nichts in der
> Anzeige des Fensters. Aber wenn ich dann zum übergeordneten Fenster
> wechsele und dann wieder zurück in den Ordner, dann werden die o.g. AUCH
> richtig angezeigt. Nur... was kann das auslösen?
halt bedeutet, daß der gesamte Directory-Eintrag neu geschrieben wird, und
dann mit den Daten, die beim Öffnen ggfs. "repariert" worden sind.
> Es funktioniert so bei jeder datei die man ein mal angesehen hat. Jede
> einzeln und dann nur die im jeweiligen Ordner. Und wenn man mc beendet
> und gleich wieder in dem (pwd) verzeichnis ist dann erinnert er sich
> auch an diese Dateien. Nur an die.
denn dann an? Dasselbe wie zuvor, dasselbe wie vor dem "Ansehen", oder was?
Sieghard Schicktanz
Dec 4, 2023, 4:13:07 PM12/4/23
to
Hallo Kay,
Du schriebst am Sun, 3 Dec 2023 23:14:35 +0100:
> Das ist allerdings ein lokales Dateisystem und der mc wird auch lokal
> aufgerufen, als root.
Ja, das habe ich auch so angenommen.
> > Natürlich ändert ein "Rescan" nichts - die ausgewerteten Daten ändern
> > sich ja dadurch nicht.
>
> Ich meinte das 'rescan' das mc im Menü des Ordner-panels anbietet. Ich
> denke der liest dabei nur den ordner neu ein.
Das hatte ich auch gemeint, und so läuft das ja auch: Ctrl-R zeigt den
aktuellen Zustand der Directory, auch wenn da was "von außen", per
Netzwerk, geändert wurde.
> > Vielleicht ein ungültiges Datum - je nach Art des Filesystems ggfs.
...
verwischen. Bei solchen Problemen _vermeidet_ man _jegliche_ Änderungen.
...
> Den Punkt hab ich im OP leider vergessen zu erwähnen.
Auch, ob das _nur_ der mc "sagt" oder auch das System-"stat".
...
und der sieht man nicht mehr an, wie der "mount"-Befehl aussah, z.B. ob da
ein explzites "-t ext4" drinstand. Wenn das dann tatsächlich ext3 oder 2
ist, dann passt das halt nicht, jedenfalls nicht überall.
> > Dann
> > ändert der Aufruf von "file" diesen Wert natürlich, und wenn der vorher
> > kaputt war, passt das nachher (beim automatischen "Re-Scan") wieder.
>
> Naja, wie ich im nebenpost schon schrieb: 'file datei' und dann ein
> verzeichnis hoch und wieder zurück und dann merkt mc sich die korrekten
> werte der datei. Auch nachdem man ihn beendete und gleich neu startet in
> dem verzeichnis.
Klar - dann isr der Directory-Eintrag ja _auf der Platte_ geändert. Aber um
(D?)ein Mißverständnis zu vermeiden: _nicht_ der "mc" "merkt" sich da was,
das ist damit im Filesystem eingetragen.
...
in Ruhe überlegen, was zu tun ist. Sind die relevanten Dateien kopiert und
in Ordnung, dann kannst Du die Platte ja löschen, dann geht nichts mehr
kaputt.
> >> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
> >> oder was sonst?
> >
> > Eher was sonst, schätze ich. Ich würde dem Filesystem nicht trauen.
> > (Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
> > _einwandfrei_ befindet... Besser noch ein scan damit.)
>
> Tut er. Insgesamt PASSED. Öhm, nur ein paar Details die ich auch grad
> entdeckte...
>
> Siehe 1, 7 und 195 bei denen mir nicht klar ist ob die am Alter liegen
> und evtl. früher schon oder aktuell auftraten.
Ja, die Werte schauen schon _sehr_ hoch aus
Bei meinen auch schon älteren HDDs (eine mit "Reallocated sectors") sind
die alle 0 bis auf einen (1 Raw_Read_Error_Rate, mit 140).
Möglicherweise ist da an der Mechanik was leicht dejustiert.
Sind die Antwortzeiten und die Übertragungsgeschwindigkeit normal? Wenn
nicht, ist die Platte "recycling-fähig"... (Tät'ich mal sagen.)
(Das ist auch dann so, wenn das an einer Änderung der Einbaulage läge,
ältere Platten waren da ggfs. etwas empfindlich.)
Du schriebst am Sun, 3 Dec 2023 23:14:35 +0100:
> Das ist allerdings ein lokales Dateisystem und der mc wird auch lokal
> aufgerufen, als root.
> > Natürlich ändert ein "Rescan" nichts - die ausgewerteten Daten ändern
> > sich ja dadurch nicht.
>
> Ich meinte das 'rescan' das mc im Menü des Ordner-panels anbietet. Ich
> denke der liest dabei nur den ordner neu ein.
aktuellen Zustand der Directory, auch wenn da was "von außen", per
Netzwerk, geändert wurde.
> > Vielleicht ein ungültiges Datum - je nach Art des Filesystems ggfs.
> Glaube ich nicht da NUR mc das nicht richtig anzeigt. Direkt in der
> shell oder in der shell die mc unter den panels laufen hat (mit
> Control-O zu erreichen) wird es ja richtig angezeigt. Oder, was ich für
> richtig hielte!
Es kann evtl. trotzdem was falsch sein.
> shell oder in der shell die mc unter den panels laufen hat (mit
> Control-O zu erreichen) wird es ja richtig angezeigt. Oder, was ich für
> richtig hielte!
...
> Die sind nur zw. Erleichterung dort gesetzt da dies eine reine
Naja, "Erleichterung"... Damit hast Du schonmal angefangen, Spuren zu
> Die sind nur zw. Erleichterung dort gesetzt da dies eine reine
verwischen. Bei solchen Problemen _vermeidet_ man _jegliche_ Änderungen.
...
> Das ist ein Punkt. Wenn ich versuche mit mc so eine rote datei zu
> kopieren oder verschieben dann meldet mc "could not stat file ..."
_Das_ ist doch schon ein Hinweis. Und was sagt "stat" direkt im Terminal?
> kopieren oder verschieben dann meldet mc "could not stat file ..."
> Den Punkt hab ich im OP leider vergessen zu erwähnen.
...
> > Da der "file"-Aufruf für den "mc" vollkommen transparent ist, soweit der
> > nichts am Directory-Eintrag verändert, kann das nur heißen, daß dieser
> > halt doch nicht in Ordnung war - ggfs. Mount-Option "atime" gesetzt?
>
> aus der fstab:
> /dev/sdc1 on /data type ext4 (rw,relatime,errors=remount-ro)
Nein, das ist _nicht_ "aus der fstab". Das ist aus der Ausgabe von "mount",
> > nichts am Directory-Eintrag verändert, kann das nur heißen, daß dieser
> > halt doch nicht in Ordnung war - ggfs. Mount-Option "atime" gesetzt?
>
> aus der fstab:
> /dev/sdc1 on /data type ext4 (rw,relatime,errors=remount-ro)
und der sieht man nicht mehr an, wie der "mount"-Befehl aussah, z.B. ob da
ein explzites "-t ext4" drinstand. Wenn das dann tatsächlich ext3 oder 2
ist, dann passt das halt nicht, jedenfalls nicht überall.
> > Dann
> > ändert der Aufruf von "file" diesen Wert natürlich, und wenn der vorher
> > kaputt war, passt das nachher (beim automatischen "Re-Scan") wieder.
>
> Naja, wie ich im nebenpost schon schrieb: 'file datei' und dann ein
> verzeichnis hoch und wieder zurück und dann merkt mc sich die korrekten
> werte der datei. Auch nachdem man ihn beendete und gleich neu startet in
> dem verzeichnis.
(D?)ein Mißverständnis zu vermeiden: _nicht_ der "mc" "merkt" sich da was,
das ist damit im Filesystem eingetragen.
...
> > zusammenpassen. Aber zumindest die Directory-Einträge sind offenbar
> > "faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das
> > mußt Du aber für jedes File wohl oder übel einzeln prüfen...
>
> Testdisk? oder was würdest du vorschlagen?
Erstmal keine weiteren Experimente, das sichern, was Du brauchst, und dann
> > "faul", und damit könnten auch die "Nutzdaten" fehlerhaft sein - das
> > mußt Du aber für jedes File wohl oder übel einzeln prüfen...
>
> Testdisk? oder was würdest du vorschlagen?
in Ruhe überlegen, was zu tun ist. Sind die relevanten Dateien kopiert und
in Ordnung, dann kannst Du die Platte ja löschen, dann geht nichts mehr
kaputt.
> >> Kann das ein Problem mit einer Falschen Einstellung im mc selbst sein
> >> oder was sonst?
> >
> > Eher was sonst, schätze ich. Ich würde dem Filesystem nicht trauen.
> > (Und der Platte allenfalls soweit, wie ein "smartctl -a" sie für
> > _einwandfrei_ befindet... Besser noch ein scan damit.)
>
> Tut er. Insgesamt PASSED. Öhm, nur ein paar Details die ich auch grad
> entdeckte...
>
> Siehe 1, 7 und 195 bei denen mir nicht klar ist ob die am Alter liegen
> und evtl. früher schon oder aktuell auftraten.
Bei meinen auch schon älteren HDDs (eine mit "Reallocated sectors") sind
die alle 0 bis auf einen (1 Raw_Read_Error_Rate, mit 140).
Möglicherweise ist da an der Mechanik was leicht dejustiert.
Sind die Antwortzeiten und die Übertragungsgeschwindigkeit normal? Wenn
nicht, ist die Platte "recycling-fähig"... (Tät'ich mal sagen.)
(Das ist auch dann so, wenn das an einer Änderung der Einbaulage läge,
ältere Platten waren da ggfs. etwas empfindlich.)
Lutz Falke
Dec 4, 2023, 4:58:23 PM12/4/23
to
Jens Schüßler schrieb:
"file" geheilt wurden.
Er meint eine Ausgabe der Art:
Left File Command Options Right
┌<─ ~/temp/test ─────────────.[^]>┐┌<─ ~/temp/test ─────────────.[^]>┐
│.n Name │ Size │Modify time ││.n Name │ Size │Modify time │
│/.. │UP--DIR│Dec 4 22:26││/.. │UP--DIR│Dec 4 22:26│
│?test1 │ 0│Jan 1 1970││?test1 │ 0│Jan 1 1970│
│?test2 │ 0│Jan 1 1970││?test2 │ 0│Jan 1 1970│
│?test3 │ 0│Jan 1 1970││?test3 │ 0│Jan 1 1970│
│ │ │ ││ │ │ │
│ │ │ ││ │ │ │
│ │ │ ││ │ │ │
├─────────────────────────────────┤├─────────────────────────────────┤
│UP--DIR ││UP--DIR │
└──────────────── 65G/1690G (3%) ─┘└──────────────── 65G/1690G (3%) ─┘
$ [^]
1Help 2Menu 3View 4Edit 5Copy 6Re~ov 7Mkdir 8De~te 9Pu~Dn10Quit
Das habe ich provoziert, indem ich dem Verzeichnis das X-Bit entzogen
und dann den mc gestartet habe. Das ist aber nicht Kays Problem, die
Ausgabe sieht nur genauso aus. (Hier streikt dann auch ls und der mc
meckert "Cannot change directory".)
Die Dateirechte auf 0777 setzen sollte nur mögliche Rechteprobleme
ausräumen, ansonsten ist das eher nicht sinnvoll. Wichtig sind dabei
aber sowieso die Rechte auf dem Verzeichnis bzw. auf dem ganzen Pfad
dahin. Zum Lesen der Dateieigenschaften braucht man die Rechte am
Verzeichnis nicht an der Datei. So ein "chmod -R" bügelt da aber
eiskalt über Dateien und Verzeichnisse. In dem Fall müssten dann auch
alle Verzeichnisse Mode 777 haben.
Das geht auch mit chmod eleganter, aber die Syntax dazu kann ich mir
nicht merken. Die Rechte von Unterverzeichnissen anpassen mache ich
bei Bedarf mit
$ find $STARTPUNKT -type d -exec chmod $MODE '{}' +
das kann ich mir besser merken.
Lutz
> * Lutz Falke <lutz...@gmx.de> [03-12-23 21:55]:
>> Kay Martinen schrieb:
>>> Am 03.12.23 um 11:05 schrieb Jens Schüßler:
>>>> * Kay Martinen <use...@martinen.de> [02-12-23 20:22]:
>> Kay Martinen schrieb:
>>> Am 03.12.23 um 11:05 schrieb Jens Schüßler:
>>>> * Kay Martinen <use...@martinen.de> [02-12-23 20:22]:
>> Grün mit * davor ist eine ausführbare Datei. Das ligt daran, dass Kay
>> in seinem Versuch oben das x-Bit überall gesetzt hat. Und laut
>
> Demnach müßten aber *alle* Dateien bei ihm grün sein, hat er
> doch
>>>>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle
>>>>> dateien auf 0777 und root:root zu setzen aber das änderte auch nichts
>>>>> an dem Problem.
>
> Werden sie aber anscheinend nicht. Warum er die Videodateien aber alle
> auf 777 und root setzt ist mir auch ein Rätsel.
"Grün" sind nur die Dateien, die durch magisches Handauflegen mittels
>> in seinem Versuch oben das x-Bit überall gesetzt hat. Und laut
>
> Demnach müßten aber *alle* Dateien bei ihm grün sein, hat er
> doch
>>>>> Ich habe vorab schon versucht mit 'chown -R' und 'chmod -R' alle
>>>>> dateien auf 0777 und root:root zu setzen aber das änderte auch nichts
>>>>> an dem Problem.
>
> Werden sie aber anscheinend nicht. Warum er die Videodateien aber alle
> auf 777 und root setzt ist mir auch ein Rätsel.
"file" geheilt wurden.
Er meint eine Ausgabe der Art:
Left File Command Options Right
┌<─ ~/temp/test ─────────────.[^]>┐┌<─ ~/temp/test ─────────────.[^]>┐
│.n Name │ Size │Modify time ││.n Name │ Size │Modify time │
│/.. │UP--DIR│Dec 4 22:26││/.. │UP--DIR│Dec 4 22:26│
│?test1 │ 0│Jan 1 1970││?test1 │ 0│Jan 1 1970│
│?test2 │ 0│Jan 1 1970││?test2 │ 0│Jan 1 1970│
│?test3 │ 0│Jan 1 1970││?test3 │ 0│Jan 1 1970│
│ │ │ ││ │ │ │
│ │ │ ││ │ │ │
│ │ │ ││ │ │ │
├─────────────────────────────────┤├─────────────────────────────────┤
│UP--DIR ││UP--DIR │
└──────────────── 65G/1690G (3%) ─┘└──────────────── 65G/1690G (3%) ─┘
$ [^]
1Help 2Menu 3View 4Edit 5Copy 6Re~ov 7Mkdir 8De~te 9Pu~Dn10Quit
Das habe ich provoziert, indem ich dem Verzeichnis das X-Bit entzogen
und dann den mc gestartet habe. Das ist aber nicht Kays Problem, die
Ausgabe sieht nur genauso aus. (Hier streikt dann auch ls und der mc
meckert "Cannot change directory".)
Die Dateirechte auf 0777 setzen sollte nur mögliche Rechteprobleme
ausräumen, ansonsten ist das eher nicht sinnvoll. Wichtig sind dabei
aber sowieso die Rechte auf dem Verzeichnis bzw. auf dem ganzen Pfad
dahin. Zum Lesen der Dateieigenschaften braucht man die Rechte am
Verzeichnis nicht an der Datei. So ein "chmod -R" bügelt da aber
eiskalt über Dateien und Verzeichnisse. In dem Fall müssten dann auch
alle Verzeichnisse Mode 777 haben.
Das geht auch mit chmod eleganter, aber die Syntax dazu kann ich mir
nicht merken. Die Rechte von Unterverzeichnissen anpassen mache ich
bei Bedarf mit
$ find $STARTPUNKT -type d -exec chmod $MODE '{}' +
das kann ich mir besser merken.
Lutz
Sieghard Schicktanz
Dec 5, 2023, 2:13:06 PM12/5/23
to
Hallo Lutz,
Du schriebst am Mon, 4 Dec 2023 21:58:20 -0000 (UTC):
> Er meint eine Ausgabe der Art:
...
eines, wohl weil der sich am "d"-Bit in den Rechten orientiert.
Wenn jemand "der Einfachheit halber" alles auf 0777 setzt, dann ist das
aber auch kein Hindernis für Verzeichnisbearbeitung, damit wird schließlich
für jeden alles erlaubt.
Du schriebst am Mon, 4 Dec 2023 21:58:20 -0000 (UTC):
> Er meint eine Ausgabe der Art:
> Das habe ich provoziert, indem ich dem Verzeichnis das X-Bit entzogen
> und dann den mc gestartet habe. Das ist aber nicht Kays Problem, die
> Ausgabe sieht nur genauso aus. (Hier streikt dann auch ls und der mc
> meckert "Cannot change directory".)
Das ficht aber "root" nicht an, für den ist das Verzeichnis immer noch
> und dann den mc gestartet habe. Das ist aber nicht Kays Problem, die
> Ausgabe sieht nur genauso aus. (Hier streikt dann auch ls und der mc
> meckert "Cannot change directory".)
eines, wohl weil der sich am "d"-Bit in den Rechten orientiert.
Wenn jemand "der Einfachheit halber" alles auf 0777 setzt, dann ist das
aber auch kein Hindernis für Verzeichnisbearbeitung, damit wird schließlich
für jeden alles erlaubt.
0 new messages