DIR-Befehl zeigt falsche Verzeichnisse an!

[druckerheini 12]

Hallo zusammen,

 

hier habe ich ein ganz seltsames Phänomen, bei dem ich mich nicht erinnern kann, dass es mir schon einmal vorgekommen ist, weder zu seligen alten DOS-Zeiten noch mit einer der Windows-Versionen der letzten 30 Jahre: Ein DIR-Befehl zeigt manchmal falsche Verzeichnisse an! Aufgefallen ist mir das bei einem kleinen Script, das den Errorlevel eines DIR abfragt, um herauszufinden, ob es ein Verzeichnis schon gibt.

 

Die Verzeichnisse liegen in einem übergeordneten Verzeichnis auf einer Netzwerkfreigabe eines älteren Synology-NAS und haben immer die selbe Struktur: Vierstellige Ziffernfolge, Unterstrich, beliebig lange Folge aus Buchstaben und Ziffern. Siehe Screenshot:

 

 

Hier sieht man auch schon den Fehler: Ein DIR mit dem Muster "074*" findet auch das Verzeichnis, das mit "0376" beginnt!

 

Doch es wird noch schräger: Benenne ich das Verzeichnis "0376_haxxxx" um, indem ich z. B. ein Zeichen ändere, anfüge oder lösche, dann wird das Verzeichnis von obigem DIR nicht mehr gefunden. Benenne ich es wieder zurück, ist der Fehler wieder da. Es scheint also mit dem konkreten Verzeichnisnamen zusammenzuhängen.

 

Weitere Tests ergaben:

 

• Das Phänomen tritt auch von einem anderen PC aus auf und betrifft dieselben Verzeichnisse (1x Windows 10 Pro, 1x Windows 11 Pro, jeweils 22H2, 64 Bit, Patchstand Februar 2023).
• Dieses Verzeichnis "0376_haxxx" ist nicht das einzige,  das falsch angezeigt wird. Es betrifft vielleicht 5% der ca. 1000 vorhandenen Verzeichnisse. Ein Muster konnte ich nicht erkennen.
• Kopiere ich die Verzeichnisse in ein anderes übergeordnetes Verzeichnis, tritt das Problem dort auch auf, und zwar mit exakt denselben Nummern.

 

Zuerst hatte ich die Synology im Verdacht, dass dort im Dateisystem etwas nicht in Ordnung ist, obwohl sie nie irgendwelche Fehler gemeldet hat. Doch dann versuchte ich es per Powershell mit Get-ChildItem, und dort ist alles korrekt, von beiden PCs aus. Das lässt mich dann wieder an der Synology-Hypothese zweifeln.

 

Hat jemand eine Idee, was hier vorgehen könnte oder was ich noch testen könnte?

 

Danke

 

 

[testperson 1.707]

Hi,

 

könnte das in diese Richtung gehen / aus dieser Richtung kommen: Sucherverhalten von "dir" anpassen - Windows Server Forum - MCSEboard.de

 

Gruß

Jan

 

[NilsK 2.957]

Moin,

 

an sowas denke ich dabei auch. @druckerheini, versuch mal

dir /X

 

Hilft das Ergebnis, die Sache aufzuklären?

 

Gruß, Nils

 

[daabm 1.366]

Man könnte das ja mal statt mit "DIR" per Powershell anschauen - aber ich kann da nur bedingt helfen, 8.3 Namen hab ich ausgerottet

 

[NilsK 2.957]

Moin,

 

Hat er schon, da gibt es den Fehler nicht.

 

Gruß, Nils

[druckerheini 12]

Zitat

dir /x

 

Bingo - das war der entscheidende Hinweis. Danke Dir dafür. Tatsächlich unterstützt die Synology defaultmäßig auch 8+3-Namen, und das genannte Verzeichnis "0376_haxxxx" hat einen 8+3-Namen, der aus welchen Gründen auch immer mit "074" beginnt. Und der Sternchenoperator von "dir" lässt offensichtlich auch diese Verzeichnisse durch den Filter, selbst wenn man den Parameter /x nicht verwendet.

 

Bislang dachte ich auch, die 8+3-Namen würden in den ersten 6 (Standard-) Zeichen mit dem normalen Datei-/Verzeichnisnamen übereinstimmen. Eine kurze Prüfung auf der Systempartition meines eigenen PCs ergab, dass das fast immer der Fall ist, aber auch hier gibt es vereinzelt Ausreißer, z. B. unterhalb von C:\Program Files:

 

06.12.2022  16:57    <DIR>          WINDOW~1     Windows Defender
15.02.2023  07:55    <DIR>          WIF4A9~1     Windows Defender Advanced Threat Protection
14.12.2022  13:33    <DIR>          WINDOW~2     Windows Mail
08.09.2022  04:13    <DIR>          WI54FB~1     Windows Media Player
07.12.2019  15:54    <DIR>          WI7A8C~1     Windows Multimedia Platform
06.12.2022  15:54    <DIR>          WINDOW~3     Windows NT
08.09.2022  04:13    <DIR>          WI8A19~1     Windows Photo Viewer
07.12.2019  15:54    <DIR>          WIBFE5~1     Windows Portable Devices
07.12.2019  10:31    <DIR>          WINDOW~4     Windows Security

 

(Als schnelle Lösung werde ich in dem Script an das "dir" nun noch ein "find" oder "findstr" anhängen, um die Existenz zu prüfen; irgendwann später stelle ich es dann auf PowerShell um.)

bearbeitet 16. März 2023 von druckerheini