Jump to content

Dateihandling bei Dateinamen mit Leerzeichen (CHR 32)


Finanzamt
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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!

Link zu diesem Kommentar

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 :D

 

 

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 von Gu4rdi4n
Link zu diesem Kommentar

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!

 

 

Link zu diesem Kommentar

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 von MurdocX
Link zu diesem Kommentar

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!

Link zu diesem Kommentar

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
 

Link zu diesem Kommentar

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

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...