Discussion:
MC Ordnerfenster Rote ?Dateien mit Null Byte
(zu alt für eine Antwort)
Kay Martinen
2023-12-02 20:22:59 UTC
Permalink
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?" :-)
Jens Schüßler
2023-12-03 10:05:27 UTC
Permalink
Post by 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. 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
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
2023-12-03 17:48:53 UTC
Permalink
Post by Jens Schüßler
Post by 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. 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
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,
Ja, der Default-Skin ist aktiv.
Post by Jens Schüßler
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.


Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Lutz Falke
2023-12-03 21:55:09 UTC
Permalink
Post by Kay Martinen
Post by Jens Schüßler
Post by 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. 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.
Post by Kay Martinen
Post by Jens Schüßler
Post by Kay Martinen
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.
Post by Kay Martinen
Post by Jens Schüßler
Post by Kay Martinen
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.
Post by Kay Martinen
Post by Jens Schüßler
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.
Post by Jens Schüßler
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.
Post by Kay Martinen
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. ;)
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
'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.
Post by Kay Martinen
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.
Post by Kay Martinen
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
Jens Schüßler
2023-12-04 09:35:51 UTC
Permalink
Post by Lutz Falke
Post by Kay Martinen
Post by Jens Schüßler
Post by 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. 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
Dateisystem einen Schlag hatte, bzw. wie sich später herausstellte die Platte.
Post by Lutz Falke
Post by Kay Martinen
Post by Jens Schüßler
Post by Kay Martinen
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
lassen, das wird hier auch in grün angezeigt.
Post by Lutz Falke
Post by Kay Martinen
Post by Jens Schüßler
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.
Post by Jens Schüßler
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
doch
Post by Lutz Falke
Post by Kay Martinen
Post by Jens Schüßler
Post by Kay Martinen
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.

Jens
Lutz Falke
2023-12-04 21:58:20 UTC
Permalink
Post by Jens Schüßler
Post by Lutz Falke
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
Post by Lutz Falke
Post by Kay Martinen
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
"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
2023-12-05 19:10:12 UTC
Permalink
Hallo Lutz,
...
Post by Lutz Falke
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
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.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Christian Garbs
2023-12-04 17:33:14 UTC
Permalink
Mahlzeit!
Post by Kay Martinen
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.
Sieghard Schicktanz
2023-12-04 19:51:34 UTC
Permalink
Hallo Kay,
Post by Kay Martinen
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.
Post by Kay Martinen
Node: ---------- (0000)
Auch falsch
Post by Kay Martinen
Attributes: ----//---e-------
(das // soll viele --- darstellen)
Links: 0
Noch was "unmögliches"
...
Post by Kay Martinen
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
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?
Post by Kay Martinen
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.
Post by Kay Martinen
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?
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Sieghard Schicktanz
2023-12-03 20:10:14 UTC
Permalink
Hallo Kay,
Post by 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
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.
Post by Kay Martinen
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?
Post by Kay Martinen
'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?
Post by Kay Martinen
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.
Post by Kay Martinen
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?
Post by Kay Martinen
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.
Post by Kay Martinen
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...
Post by Kay Martinen
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
-----------------------------------------------------------
Kay Martinen
2023-12-03 22:14:35 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Kay,
Post by 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
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
aufgerufen, als root.
Post by Sieghard Schicktanz
Post by Kay Martinen
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.
Post by Sieghard Schicktanz
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!
Post by Sieghard Schicktanz
Post by Kay Martinen
'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.
Post by 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.
Post by Sieghard Schicktanz
Post by Kay Martinen
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.
Post by Sieghard Schicktanz
Post by Kay Martinen
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.
Post by Sieghard Schicktanz
Post by Kay Martinen
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)
Post by Sieghard Schicktanz
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.
Post by Sieghard Schicktanz
Post by Kay Martinen
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?
Post by Sieghard Schicktanz
Post by Kay Martinen
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


Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Lutz Falke
2023-12-04 11:13:58 UTC
Permalink
Post by Kay Martinen
Post by 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
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?
Post by Kay Martinen
Post by Sieghard Schicktanz
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.
Post by Kay Martinen
Post by Sieghard Schicktanz
Post by Kay Martinen
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
[...]
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
Sieghard Schicktanz
2023-12-04 20:17:32 UTC
Permalink
Hallo Kay,
Post by Kay Martinen
Das ist allerdings ein lokales Dateisystem und der mc wird auch lokal
aufgerufen, als root.
Ja, das habe ich auch so angenommen.
Post by Kay Martinen
Post by Sieghard Schicktanz
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.
Post by Kay Martinen
Post by Sieghard Schicktanz
Vielleicht ein ungültiges Datum - je nach Art des Filesystems ggfs.
...
Post by Kay Martinen
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.
...
Post by Kay Martinen
Die sind nur zw. Erleichterung dort gesetzt da dies eine reine
Naja, "Erleichterung"... Damit hast Du schonmal angefangen, Spuren zu
verwischen. Bei solchen Problemen _vermeidet_ man _jegliche_ Änderungen.
...
Post by Kay Martinen
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?
Post by Kay Martinen
Den Punkt hab ich im OP leider vergessen zu erwähnen.
Auch, ob das _nur_ der mc "sagt" oder auch das System-"stat".

...
Post by Kay Martinen
Post by Sieghard Schicktanz
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)
Nein, das ist _nicht_ "aus der fstab". Das ist aus der Ausgabe von "mount",
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.
Post by Kay Martinen
Post by Sieghard Schicktanz
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.

...
Post by Kay Martinen
Post by Sieghard Schicktanz
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
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.
Post by Kay Martinen
Post by Sieghard Schicktanz
Post by Kay Martinen
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.)
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Jan Novak
2023-12-04 07:31:54 UTC
Permalink
Post by 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.

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
2023-12-04 08:25:26 UTC
Permalink
Post by Jan Novak
Post by 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
Beiden Ordnerfenster des MC.
Post by Jan Novak
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.

Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Loading...