Dateihandling bei Dateinamen mit Leerzeichen (CHR 32)

[Finanzamt 76]

Hallöchen!

Irgendwie steh ich auf'm Schlauch, auch wenn es schon fast 11:00 ist - Hab ich was nicht mitgekriegt? Mein Prob:

Windows 10pro,
CMD aufgerufen.
Wechsel in ein Verzeichnis mit Dateien, deren Dateinamen allesamt mit 4 Ziffern beginnen, es folgen ein Leerzeichen und weiterer Text.
Einige der Dateien habe ich bearbeitet und unter gleichem Namen bis auf den Buchstaben "n" hinter den 4 Ziffern gespeichert.

COPY ????n*.odt y:\TEMP kopiert aber nicht nur die mit "n" markierten Dateien, sondern auch noch die Dateien, die hinter den 4 Ziffern ein Leerzeichen haben, wenn der dann folgende Text mit einem "N" beginnt.

Klärt mich bitte wer auf? Gibts es evtl. einen "SET EXACT ON" - Schalter? Wo kann ich ggf was nachlesen?
Dankeschön und gegrüßt!

[Gu4rdi4n 60]

leerzeichen werden generell scheinbar ignoriert

 

ich habe gerade eine datei erstellt namens "12 34nblubb.txt" und diese mit "del 1234n*.txt" löschen lassen.

Er löscht diese, obwohl ein leerzeichen drin ist.

 

Sobald ich das Sternchen rausnehme und "del 1234nblubb.txt" abschicke, sagt er mir die Datei kann nicht gefunden werden.

 

Hab etwas weiter getestet...

 

Echt seltsam

C:\Temp>dir
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 6893-151A

 Verzeichnis von C:\Temp

10.09.2019  14:21    <DIR>          .
10.09.2019  14:21    <DIR>          ..
10.09.2019  14:20                 0 1 2 3 4 n b l u b b.txt
               1 Datei(en),              0 Bytes
               2 Verzeichnis(se), 37.770.928.128 Bytes frei

C:\Temp>del 1234nblubb.txt
C:\Temp\1234nblubb.txt konnte nicht gefunden werden

C:\Temp>del 1234nblub*.txt
C:\Temp\1234nblub*.txt konnte nicht gefunden werden

C:\Temp>del 1234nblu*.txt
C:\Temp\1234nblu*.txt konnte nicht gefunden werden

C:\Temp>del 1234nbl*.txt
C:\Temp\1234nbl*.txt konnte nicht gefunden werden

C:\Temp>del 1234nb*.txt

C:\Temp>dir
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 6893-151A

 Verzeichnis von C:\Temp

10.09.2019  14:22    <DIR>          .
10.09.2019  14:22    <DIR>          ..
               0 Datei(en),              0 Bytes
               2 Verzeichnis(se), 37.537.415.168 Bytes frei

Ha, das hat mich jetzt nicht losgelassen und ich wollte es auch wissen

 

 

Hier die Lösung:

 

Dos Befehle nutzen auch das 8.3 Format.

wenn du deinen Ordner mit dir /x ansiehst, dann wird dir der name ohne Leerzeichen angezeigt.

 

Was ich nicht getestet habe ist, ob das ganze auch bei Robocopy passiert. 

 

bearbeitet 10. September 2019 von Gu4rdi4n

[Finanzamt 76]

Hi!

Ich habe auch noch weiter rumgemacht ;-) 

1. ist die Sache nicht spezifisch für  Windows 10 pro. Ich habe es unter XP reproduzieren können.

2. wenn ich das Leerzeichen (CHR 32) durch das andere Leerzeichen (CHR 255) ersetze, ändert sich nichts

3. wenn ich das Leerzeichen durch ■ (CHR 254) ersetze, ändert sich auch nichts

4. wenn ich den Dateinamen auf 8+3 ändere (9999■nnn.xxx), ändert sich auch nichts

5. wenn ich ein Zeichen kleiner CHR 127 eingebe, sind die Ausgaben korrekt - auch bei CHR 126

6. wenn ich den Paragraphen § nehme, ist es wieder falsch 

 

Dass man mit Dateien nur dann wirklich 100%ig sicher arbeiten kann, wenn man ausschließlich die Ziffern 0-9, die Buchstaben des englischen Alphabetes, $_ verwendet, scheint sich wieder zu beweisen. Das hat aber nichts mehr mit der sog. Realität zu tun.

 

Robocopy kopiert alles sauber ... aber: ein /XF mit Obigem greift nicht.

 

Das mit 8.3 ist sicher ein Hinweis. Jedoch müsste es m.E. auch erklären, dass Dir /X eine Datei "9999 nnn.xxx" mit

9999NN~.xxx     9999 nnn.xxx

wiedergibt.

 

Ich werd bei Gelegenheit mal schauen, was DosBox und vDosPlus liefern. Schonmal Dank und

gegrüßt!

 

 

[MurdocX 953]

Schon mal mit der Powershell probiert?  

 

Edit:

Get-ChildItem -Path C:\ | Where-Object { $_.Name -like '* * *' }

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-r---       29.08.2019     11:02                Program Files (x86)

Wäre ein einfaches Beispiel für Namen mit 2 Leerzeichen. Das kann beliebig verändert werden.

bearbeitet 10. September 2019 von MurdocX

[Finanzamt 76]

Hallo!

Nein, habe es damit nicht probiert. Ich fände es auch nicht wirklich prickelnd, für so eine einfache Sache wie das Kopieren mit Wildcards was anderes als Copy zu verwenden ... Deshalb ja auch meine Anfrage "hab ich was nicht mitgekriegt?" 

Wenn das Beobachtete tatsächlich ein Windows "Feature" ist [Dateinamen zuzulassen, die dann nicht sauber via Wildcard-Konstrukt separiert werden können], dann wäre das ein so fetter Bug, dass ich's nicht glauben kann. Das Problem tauchte zur unmöglichsten Zeit an anderen Stellen wieder auf und es bliebe nur, alle Dateien mit "merkwürdigen" Zeichen umzubenennen, alle Verknüpfungen zu korrigieren, jede Datei aus anderer Quelle zu checken... 

Weil das so unglaublich ist, denke ich weiterhin, dass das Problem zwischen meinen Ohren liegt - auch wenn die Einsicht nicht leicht fällt. Ich habe garantiert was übersehen, überlesen oder einfach nur einen dummen Fehler gemacht. Wäre schön, wenn mich jemand korrigierte.

Gegrüßt!

[MurdocX 953]

Das Finanzamt macht doch nie Fehler 

 

Über Regex kannst die „ungültigen“ Zeichen Filtern oder die Dateien umbenennen. 

[Finanzamt 76]

Puhhh - es geht doch!

 

COPY ????n*.odt y:\Temp      [geht nicht]
COPY "????n *.odt" y:\Temp   [so gehts: Leerzeichen zwischen n und *]

 

Das betrifft nicht allein COPY, sondern auch DIR, MOVE, XCOPY, DEL ... 

 

Das Leerzeichen, aber auch viele** "unübliche" Zeichen ( >CHR 128, <CHR 32, sofern sie sich im Dateinamen verwenden lassen ) werden von Wildcards nicht erfasst***. Deshalb muss man sie bei Selektionen explizit eintragen und den gesamten Selektionsbegriff in " " setzen.

 

Warum die von den Wildcards nicht erfasst werden, interessiert mich natürlich immer noch. Hat wer Ideen? 

Gegrüßt!

 

** Ich habe nicht alle ausprobiert, nur  ■, §, ▀, »,  ▒, als Stichproben 
*** vgl. Gu4rdi4n, Post #2, Zeile 1
 

[NilsK 2.957]

Moin,

 

das sind eben die Beschränkungen des CMD-Interpreters. Solange du Basics wie copy usw. benutzt, bist du auf deren Spezifikationen festgelegt.

 

Aus gutem Grund ist Abwärtskompatibilität bei Microsoft sehr wichtig, das ist eine wesentliche Ursache für deren kommerziellen Erfolg. Daher haben Uralt-Techniken eben oft auch uralte Beschränkungen. Manche Modernisierungen sind dann nachträglich drangestrickt, so etwa die Unterstützung langer Dateinamen und zusätzlicher Zeichen. Und genau in dem Bereich spielt sich das Phänomen ab, das du beobachtet hast.

 

Da kann man sich natürlich auf den Standpunkt stellen, dass Windows "fette Bugs" habe und dass man für "so eine einfache Sache" nur die Basis-Tools verwenden will - aber dann kriegt man eben auch nur das, was die Basis-Tools halt können.

 

Gruß, Nils