Workstation: erste Tests...

[Axel Berger]

Hanno Foest wrote:
> Sehr lustig. Ich hab memtest86+ 18 Stunden laufen lassen müssen,

Ist Memtest überhaupt noch sinnvoll? Ich kenne es aus der Zeit, als
zweistellig MB RAM viel war. Schon mit einem halben Gigabyte schafft man
es kaum noch, den ganzen Zyklus auch nur einmal durchlaufen zu lassen.
Ja, natürlich habe ich es über Nacht laufen lassen und dann auch mal
einen ganzen Tag und eine ganze Nacht, aber so richtig weit im Programm
kam es nicht.


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Arno Welzel]

Axel Berger, 2023-07-25 22:30:

Arno Welzel wrote:
Sobald die Prüfsumme weniger Bits umfasst als die geprüften
Daten, gibt es zwangsläufig Kollisionen ...
Ja, in der Praxis genügen Prüfsummen oft

Du hast natürlich vollkommen recht, es /kann/ das alles geben. Das wäre
dann ein System, das keinerlei 1-bit-Fehler aufweist, keine
2-bit-Fehler, keine Prüfsummensummenfehler, dann aber plötzlich und
gleich einen n-bit-Fehler, der rein zufällig genau an allen Prüfsummen
vorbeischrammt. Ist möglich, aber wenn, dann doch wohl ziemlich sicher
nach erheblichem Aufwand eines Geheimdienstes entstanden und nicht durch
Hardwarefehler.

Es ging mir auch nicht um die Wahrscheinlichkeit, wie oft sowas
vorkommt, sondern die falsche Annahme, dass Prüfsummen *garantieren*
könnten, dass Daten fehlerfrei sein.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-25 22:45:

Am 25.07.2023 um 20:38 schrieb Arno Welzel:
[...]
Um festzustellen, ob Daten wirklich *absolut* korrekt sind, müsste man
den vollständigen Datensatz mit einem *bekannt* korrekten Original
vergleichen. Sobald die Prüfsumme weniger Bits umfasst als die geprüften
Daten, gibt es zwangsläufig Kollisionen in der Weise, dass es garantiert
auch eine andere Bitfolge gibt, die zur selben Prüfsumme führt.

Das ist eine problematische Formulierung.

Nein, genau so ist es.

Du hast selbst geschrieben, Zitat:

\"Wenn ich zwei große identische Testläufe mache und die Resultatdateien
8 MB sind vollkommen identisch und mit plausiblem Inhalt, dann ist das
ein Beweis, daß diese Tests ohne Datenfehler abliefen.\"

Und damit hast Du ja vom Prinzip her genau das getan - zwei identische
Testläufe und anschließend die Prüfung, ob beide Ergebnisse gleich sind.

Sicher ist, daß bei 1 Bit weniger mit allerhöchster Wahrscheinlichkeit ein
wirklich vollkommen anderer Hash entsteht.

Korrekt.

Eine Kollision liegt vor, wenn zwei (deutlich) unterschiedliche Dateien
den gleichen Hash generieren.

Und das ist zwangsläufig möglich, wenn der Hash kürzer ist, als die
Ausgangsdaten, aus denen er erzeugt wurde. Bei als \"sicher\" geltenden
Hashes ist nur der Aufwand zur Auffindung zweier Bitfolgen, die den
selben Hash ergeben, extrem hoch.

MD5 gilt mittlerweile nicht mehr als sicher, weil dort Kollisionen
bekannt sind und seit 2004 ein Verfahren, mit dem man diese auch in
relativ kurzer Zeit finden kann: <http://eprint.iacr.org/2004/199.pdf>


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-26 16:37:

Am 26.07.2023 um 14:30 schrieb Gerrit Heitsch:
On 7/26/23 13:54, Helmut Schellong wrote:
Am 26.07.2023 um 06:48 schrieb Gerrit Heitsch:
On 7/25/23 22:45, Helmut Schellong wrote:

Wann immer es geht, verwende ich das Kommando \'cmp\'.
Das prüft alle Bytes auf Gleichheit.

\'diff -r\' ist auch nützlich wenn man ganze Verzeichnisbäume auf Gleichheit überprüfen will.

Ja, es gibt unter Unix viele Wege, auf Gleichheit zu prüfen.

Bespielweise auch \'rsync\' oder
find /dir1 -type f -exec cmp [-o] {} /dir2/$(basename {}) || echo ERR {} \\;

Solche Konstrukte sind nett, aber man muss aufpassen, bei Dateinamen mit SPACE (was man vermeiden
sollte) passieren oft überraschende Dinge wenn man vergisst an passenden Stellen Quotes zu verwenden.

Ja, das sowieso;
jedoch ich selbst produziere niemals Dateinamen mit enthaltenen SPACEs.
Fremde Dateien werden von mir auch entsprechend eingepflegt (oft ganz anderer Name).
Und der OS-Hersteller verwendet ebenso niemals SPACEs in Dateinamen.

Wer ist \"der OS-Hersteller\"? Welches OS? Bei Windows gibt es Dateinamen
mit Leerzeichen für sehr zentrale Verzeichnisse:

\"C:\\Program Files\"
\"C:\\Program Files (x86)\"


--
Arno Welzel
https://arnowelzel.de

 

[Gerrit Heitsch]

On 7/28/23 09:03, Arno Welzel wrote:

Helmut Schellong, 2023-07-26 16:37:

Am 26.07.2023 um 14:30 schrieb Gerrit Heitsch:
On 7/26/23 13:54, Helmut Schellong wrote:
Am 26.07.2023 um 06:48 schrieb Gerrit Heitsch:
On 7/25/23 22:45, Helmut Schellong wrote:

Wann immer es geht, verwende ich das Kommando \'cmp\'.
Das prüft alle Bytes auf Gleichheit.

\'diff -r\' ist auch nützlich wenn man ganze Verzeichnisbäume auf Gleichheit überprüfen will.

Ja, es gibt unter Unix viele Wege, auf Gleichheit zu prüfen.

Bespielweise auch \'rsync\' oder
find /dir1 -type f -exec cmp [-o] {} /dir2/$(basename {}) || echo ERR {} \\;

Solche Konstrukte sind nett, aber man muss aufpassen, bei Dateinamen mit SPACE (was man vermeiden
sollte) passieren oft überraschende Dinge wenn man vergisst an passenden Stellen Quotes zu verwenden.

Ja, das sowieso;
jedoch ich selbst produziere niemals Dateinamen mit enthaltenen SPACEs.
Fremde Dateien werden von mir auch entsprechend eingepflegt (oft ganz anderer Name).
Und der OS-Hersteller verwendet ebenso niemals SPACEs in Dateinamen.

Wer ist \"der OS-Hersteller\"? Welches OS? Bei Windows gibt es Dateinamen
mit Leerzeichen für sehr zentrale Verzeichnisse:

\"C:\\Program Files\"
\"C:\\Program Files (x86)\"

Ja, und das ist ein Fehler. Aber MS und sauberes Design...

Gerrit

 

[Arno Welzel]

Helmut Schellong, 2023-07-27 00:24:

Am 26.07.2023 um 21:40 schrieb Rupert Haselbeck:
Helmut Schellong schrieb:
[...]
Es kommt auf die Definition von \"vollkommene Datenkorrektheit\" an.
Bisher habe nur ich eine Definition für den Kontext abgegeben.

Das ist schlicht falsch. \"Vollkommene Datenkorrektheit\" impliziert ohne jede weitere Definition
eines Kontextes, dass die Daten sämtlich ohne jeden Fehler verarbeitet werden bzw. wurden.

Ja, korrekt, das definiere ich selbst ja auch andauernd so.

Die zeitliche Ebene muß einbezogen werden, andernfalls wird es ungenau und mißverstanden.

Nein, Daten sind entweder korrekt oder nicht. \"Zeit\" ist in Bezug auf
*Daten* irrelevant.

Die \"zeitliche Ebene\" kann man nur auf die *Verarbeitung* der Daten
anwenden und z.B. beobachten, dass ein Verarbeitungsprozess, der 10
Minuten dauert, korrekte Daten liefert, während bei einer Dauer von 100
Stunden die Wahrscheinlichkeit für fehlerhafte Daten höher ist, wenn man
Bitfehler nicht durch geeignete Prüfverfahren erkennen kann.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Hanno Foest, 2023-07-28 00:02:

Am 27.07.23 um 20:16 schrieb Helmut Schellong:

[memtest86+]

Test-Arten:
-----------
00  Adressentest, fortschreitende Einsen
01  Adressentest, eigene Adresse
03  Bewegte Inversionen, Einsen & Nullen
04  Bewegte Inversionen, 8-bit-Muster
05  Bewegte Inversionen, Zufallsmuster
06  Blockbewegung, 64-byte-Blöcke
07  Bewegte Inversionen, 32-bit-Muster
08  Zufallszahlensequenz
09  Modulo 20, Einsen & Nullen
10  Test auf verblassende Bits, 2 Muster
13  Hammer-Test
14  DMA-Test

Wer diese Tests mit 0 Fehlern durchläuft, hat mit extrem hoher
Wahrscheinlichkeit
ein vollkommen intaktes RAM.

Sehr lustig. Ich hab memtest86+ 18 Stunden laufen lassen müssen, bis
sich die ersten Fehler zeigten. Mit etwas mehr Pech hätten es auch 3
Tage (oder mehr) sein können.

Ja, solche Fälle kenne ich auch - memtest86+ kann auch mal 24 Stunden
fehlerfrei laufen und am Ende ist das System wegen Bitfehlern im RAM
trotzdem instabil. Das fällt dann zwar nur alle paar Monate auf, aber in
solchen Fällen ersetze ich in der Regel das RAM komplett, egal ob
memtest86+ etwas findet oder nicht.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-25 21:29:

Am 25.07.2023 um 20:21 schrieb Arno Welzel:
[...]
Ein AMD Ryzen aus der 5000er- oder 7000er-Reihe mit B550 oder X750
Chipsatz kann auch ECC. Ist halt nicht so teuer und man kann damit nicht
angeben - aber schlechter als mit einem Xeon ist das auch nicht, was die
Fehlerkorrektur betrifft.

Was immer wieder untergeht:
DDR5 hat grundsätzlich ein eingebautes ECC.
Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

AMD Ryzen 5 arbeitet mit DDR4 und unterstützt das \"zusätzliche äußere ECC\".

[...]

Eben - ein Hobby. Ist ja auch ok so. Aber das kannst Du doch auch
einfach so sagen. Oder wäre das für Dich unehrenhaft, einfach sagen
\"weil es mit Spaß macht, egal ob man das unbedingt so braucht\"?

Genau das wäre falsch - eine Verbrämung!
Ich führe ja diejenige Arbeit weiter, die ich zuvor am Arbeitplatz erbrachte.
Elektronik entwickeln und programmieren.

D.h. die Entwicklungen werden veröffentlicht?

Mein alter PC von 2006 mußte nun durch etwas Modernes ersetzt werden.
Das tat ich nach 17 Jahren.
Es erschent so, als ob so mancher nicht damit klarkommt - seltsam.

Wenn es Dir Spaß macht, kannst Du gerne auch ein ganzes Rechenzentrum
kaufen. Nur die Begründung, dass Du sowas aus brauchst, weil Du als
Ingenieur arbeitest, finde ich etwas eigenwillig.

[...]

Das ist doch schön für Dich. Ich frage mich nur, was man da so konkret
tut, was zwingend so eine Hardware voraussetzt. Aber für Hobbies kann
man auch beliebig überdimensionierte Dinge anschaffen, die man
eigentlich nie wirklich *braucht*.

Ich habe da Software entwickelt, um die Daten einer alten Datenbank
auf eine moderne Datenbank transportieren zu können.
Kundenstrukturen von etwa 3500 Kunden waren darunter.
Dafür brauchte ich die Workstation nicht.

Eben.

Es macht halt Spaß. Aber dass Dir etwas einfach Spaß macht, würdest Du
wohl nie zugeben. Nein, es muss begründet werden mit sachlichen
Anforderungen.

Ich habe vor einigen Wochen 33000 Dateien im Umfang von 110 GB analysiert
und bestimmte Daten mit Suchmustern herausgefiltert, mit einem Multitasking-Shell-Skript.
DAFÜR und für Ahnliches brauche ich die Workstation.

Und das Ergebnis der Analyse dieser Dateien wird dann irgendwann
veröffentlicht oder war eine Auftragsarbeit?


--
Arno Welzel
https://arnowelzel.de

 

[Gerrit Heitsch]

On 7/28/23 09:16, Arno Welzel wrote:

Hanno Foest, 2023-07-28 00:02:

Am 27.07.23 um 20:16 schrieb Helmut Schellong:

[memtest86+]

Test-Arten:
-----------
00  Adressentest, fortschreitende Einsen
01  Adressentest, eigene Adresse
03  Bewegte Inversionen, Einsen & Nullen
04  Bewegte Inversionen, 8-bit-Muster
05  Bewegte Inversionen, Zufallsmuster
06  Blockbewegung, 64-byte-Blöcke
07  Bewegte Inversionen, 32-bit-Muster
08  Zufallszahlensequenz
09  Modulo 20, Einsen & Nullen
10  Test auf verblassende Bits, 2 Muster
13  Hammer-Test
14  DMA-Test

Wer diese Tests mit 0 Fehlern durchläuft, hat mit extrem hoher
Wahrscheinlichkeit
ein vollkommen intaktes RAM.

Sehr lustig. Ich hab memtest86+ 18 Stunden laufen lassen müssen, bis
sich die ersten Fehler zeigten. Mit etwas mehr Pech hätten es auch 3
Tage (oder mehr) sein können.

Ja, solche Fälle kenne ich auch - memtest86+ kann auch mal 24 Stunden
fehlerfrei laufen und am Ende ist das System wegen Bitfehlern im RAM
trotzdem instabil. Das fällt dann zwar nur alle paar Monate auf, aber in
solchen Fällen ersetze ich in der Regel das RAM komplett, egal ob
memtest86+ etwas findet oder nicht.

Ich hatte schon so ein Problem. Beim Kopieren von großen Files konnte es
einzelne Bitkipper geben (1 Bit defekt in 10 GB). Das Problem verschwand
als ich die DIMMs in das andere Sockelpaar gesteckt habe. Das RAM war
also OK, die Signale zwischen CPU und DIMMs hingegen an der Grenze.

Gerrit

 

[Arno Welzel]

Helmut Schellong, 2023-07-26 15:49:

Am 26.07.2023 um 12:16 schrieb Rolf Bombach:
Helmut Schellong schrieb:
[...]
Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

Da muss man sich fragen, was dieses dann eigentlich genau
tut. Fehler der Fehlerkorrektur finden? Geht das überhaupt?

Das innere ODECC arbeitet vollkommen getrennt.
Es repariert 1-Bit-Fehler.

Die Frage war, warum man serienmäßig sowas einbaut, wenn man doch auch
RAM ohne ECC billiger anbieten könnte. Die Annahme ist, dass DDR5 ohne
ECC zu viele Fehler produzieren würde, weil es da kaum noch möglich ist,
stabilen Betrieb ohne Korrekturmaßnahmen sicherzustellen.

Das ist ähnlich wie bei Festplatten mit extrem hohen Schreibdichten, wo
ein erheblicher Aufwand nötig ist, weil das, was der Lesekopf als Signal
liefert, schon lange nicht mehr direkt als Bits verarbeitbar ist.

--
Arno Welzel
https://arnowelzel.de

 

[Gerrit Heitsch]

On 7/28/23 09:23, Arno Welzel wrote:

Helmut Schellong, 2023-07-25 21:29:

Am 25.07.2023 um 20:21 schrieb Arno Welzel:
[...]
Ein AMD Ryzen aus der 5000er- oder 7000er-Reihe mit B550 oder X750
Chipsatz kann auch ECC. Ist halt nicht so teuer und man kann damit nicht
angeben - aber schlechter als mit einem Xeon ist das auch nicht, was die
Fehlerkorrektur betrifft.

Was immer wieder untergeht:
DDR5 hat grundsätzlich ein eingebautes ECC.
Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

AMD Ryzen 5 arbeitet mit DDR4 und unterstützt das \"zusätzliche äußere ECC\".

Kann man aber nur nutzen wenn das Mainboard auch mitspielt. Meines tut das.

Gerrit

 

[Andreas Fecht]

Am 28.07.2023 um 09:03 schrieb Arno Welzel:

Ja, das sowieso;
jedoch ich selbst produziere niemals Dateinamen mit enthaltenen SPACEs.
Fremde Dateien werden von mir auch entsprechend eingepflegt (oft ganz anderer Name).
Und der OS-Hersteller verwendet ebenso niemals SPACEs in Dateinamen.

Wer ist \"der OS-Hersteller\"? Welches OS? Bei Windows gibt es Dateinamen
mit Leerzeichen für sehr zentrale Verzeichnisse:

\"C:\\Program Files\"
\"C:\\Program Files (x86)\"

Das ist aber nur Maskerade!

Die beiden Ordner heißen auf Systemebene anders:

C:\\PROGRA~1
C:\\PROGRA~2

Die echten Namen bekommt man mit \"dir /X\" angezeigt.

Gruß Andreas

 

[Axel Berger]

Arno Welzel wrote:
> MD5 gilt mittlerweile nicht mehr als sicher,

Es macht aber schon einen Unterschied, ob ich mich nur gegen
Kopierfehler schützen will oder auch gegen böswillige Veränderung.


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Stefan Ram]

Andreas Fecht <forum@aftec.de> writes:
>Die beiden Ordner heißen auf Systemebene anders:

Das ist nicht die \"Systemebene\", es sind 8.3-Namen. Bei
neueren Windows-Versionen sind solche Namen entbehrlich
und können mit \"FSUTIL\" abgestellt werden. Windows kann
dann grundsätzlich weiterhin arbeiten. Da es aber trotzdem
Probleme bereiten könnte, würde ich das nicht empfehlen,
obwohl bestimmte Dateioperationen dann etwas schneller sind.

 

[Wolfgang Allinger]

On 27 Jul 23 at group /de/sci/electronics in article u9tior$1s3t7$1@dont-email.me
<rolfnospambombach@invalid.invalid> (Rolf Bombach) wrote:

Andererseits, irgendwie haben auch Kernspeicher funktioniert.
Dort kann man prinzipiell nur destruktiv auslesen.

und muss sie sofort wieder rückspeichern. Klappte hervorragend.

Nicht nur da, gabs \'verduftende\' Bits, die wiederbelebt werden müssen.
Ist also gängiges Problem bzw. Verfahren.

Bei dynamischen RAM, müssen alle paar msec die Infos \'refreshed\' werden.
Bei auf Floating Gates gespeicherten Daten gibbet den mehr oder weniger
schnellen Verschwindi.BUS Effekt.
Auch MagTapes müssen regelmäßig kontrolliert werden.

Dauerhafte Speicher sind sehr rar, besonders wenn Dauerhaft mehrere Jahre,
Jahrzehnte...Jahrtausende bedeutet.
Jajaja, ich kenne Höhlenmalerei, Steintafeln...


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Gerrit Heitsch]

On 7/27/23 14:25, Wolfgang Allinger wrote:

On 27 Jul 23 at group /de/sci/electronics in article u9tior$1s3t7$1@dont-email.me
rolfnospambombach@invalid.invalid> (Rolf Bombach) wrote:

Andererseits, irgendwie haben auch Kernspeicher funktioniert.
Dort kann man prinzipiell nur destruktiv auslesen.

und muss sie sofort wieder rückspeichern. Klappte hervorragend.

Das gleiche gilt für DRAMs, Auslesen ist destruktiv. Das
Zurückschreiben ist allerdings im RAM integriert und passiert
automatisch am Ende des Zugriffs.

Gerrit

 

[Hanno Foest]

Am 28.07.23 um 01:19 schrieb Axel Berger:

Sehr lustig. Ich hab memtest86+ 18 Stunden laufen lassen müssen,

Ist Memtest überhaupt noch sinnvoll? Ich kenne es aus der Zeit, als
zweistellig MB RAM viel war. Schon mit einem halben Gigabyte schafft man
es kaum noch, den ganzen Zyklus auch nur einmal durchlaufen zu lassen.

Kann ich so nicht bestätigen. Das mit den 18 Stunden ist ne Weile her,
es waren so 4GB, und memtest hat schon ein paar Runden geschafft.

Die andere Frage ist, was du messen willst. Wenn memtest Fehler wirft,
weiß du definitiv, daß das RAM (in dieser Konfiguration) kaputt ist. Du
kannst aber nicht verifizieren, daß es heil ist. Das ist letztendlich
das alte Verifikationsproblem aus den Erkenntniswissenschaften: Das
Ergebnis *könnte* sich morgen spontan geändert haben.

Für mich war obiges Erlebnis Anlaß, mich nach günstigen ECC Lösungen
umzusehen, und sie nach Möglichkeit (für Laptops kann man das knicken)
einzusetzen.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Sebastian Suchanek]

Thus spoke Rupert Haselbeck:

Helmut Schellong schrieb:

[...]
(Meine Festplatten kosten bereits 900 EUR.)

Jeder kauft mal zu teuer.
[...]

Das hängt allerdings davon ab, um wieviele und welche
Festplatten es geht. Für die beiden WD140EFGX in meinem
Heimserver (RAID1) habe ich im Dezember \'21 auch gute 600 EUR
bezahlt - zur damaligen Zeit ein fairer Kurs.

[...[
Meine Gründe sind überwiegend rational.

^^
Du hast da ein \"ir\" vergessen.


Tschüs,

Sebastian

--
Ich WEISS was ich tue ;-)
Und wenns mal wieder Knallt, weiss ich auch genau, warum ich
mich in den Hintern treten sollte ;-)
[Michael Buchholz in d.s.e]

 

[Arno Welzel]

Gerrit Heitsch, 2023-07-28 09:06:

On 7/28/23 09:03, Arno Welzel wrote:
Helmut Schellong, 2023-07-26 16:37:
[...]
Ja, das sowieso;
jedoch ich selbst produziere niemals Dateinamen mit enthaltenen SPACEs.
Fremde Dateien werden von mir auch entsprechend eingepflegt (oft ganz anderer Name).
Und der OS-Hersteller verwendet ebenso niemals SPACEs in Dateinamen.

Wer ist \"der OS-Hersteller\"? Welches OS? Bei Windows gibt es Dateinamen
mit Leerzeichen für sehr zentrale Verzeichnisse:

\"C:\\Program Files\"
\"C:\\Program Files (x86)\"

Ja, und das ist ein Fehler. Aber MS und sauberes Design...

Was hat \"Dateibenennung\" mit \"sauberem Design\" zu tun? Programme sollten
mit Leerzeichen in Dateinamen umgehen können. Auch unter Linux oder
macOS ist das nicht verboten. Wenn man das nicht wollte, hätte man
Leerzeichen als Teil des Dateinamens verbieten sollen - hat man aber
nicht, auch nicht unter Linux oder macOS.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Andreas Fecht, 2023-07-28 10:33:

Am 28.07.2023 um 09:03 schrieb Arno Welzel:

Ja, das sowieso;
jedoch ich selbst produziere niemals Dateinamen mit enthaltenen SPACEs.
Fremde Dateien werden von mir auch entsprechend eingepflegt (oft ganz anderer Name).
Und der OS-Hersteller verwendet ebenso niemals SPACEs in Dateinamen.

Wer ist \"der OS-Hersteller\"? Welches OS? Bei Windows gibt es Dateinamen
mit Leerzeichen für sehr zentrale Verzeichnisse:

\"C:\\Program Files\"
\"C:\\Program Files (x86)\"


Das ist aber nur Maskerade!

Die beiden Ordner heißen auf Systemebene anders:

C:\\PROGRA~1
C:\\PROGRA~2

Nein, das sind die *erzeugten* Namen in 8+3-Schreibweise für
Uralt-Software, die mit langen Dateinamen nicht umgehen kann.

> Die echten Namen bekommt man mit \"dir /X\" angezeigt.

Ähm - nein.

<https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/dir>

Alternativ \"dir /?\"

Aus obiger Website, Zitat:

/x

Zeigt die kurzen Namen an, die für Nicht-8dot3-Dateinamen generiert
werden. Die Anzeige entspricht der Anzeige mit /n, der kurze Name wird
jedoch vor dem langen Namen eingefügt.

(Zitat Ende)


--
Arno Welzel
https://arnowelzel.de