NTFS neuerdings groß/klein sensitiv?

[cumulonimbus8]

Moin!

In einem alten Programmcode prüfe ich auf Anwesenheit der «Desktop.Ini».
Dabei hat für DIR in VBA [zwecks Testen dieses Unfalls] oder ›FSO‹.FileExists (VBA, WSH) bisher die Frage nach »desktop.ini« genügt. nun findet sich auf einer externen Platte eine »Desktop.Ini« und die wird von der Suche nicht erfasst! Nur in der konkreten Schreibweise mit Großbuchstaben landen DIR und FileExists Treffer.

Das mag mir bei UNIX / Linux nicht weiter verwunderlich erscheinen - aber NTFS..?
Wie bekomme ich denn nun diese verunglückte Schreibweise erfasst? Verbockt habe ich die gewiss selbst, vor Jahren, aber dieser Aussetzer ist mir neu.

CN8

 

[Timmey92]

Ist die externe Platte evlt. mit FAT32 formatiert statt mit NTFS?

 

[alxtraxxx]

Hab sogar schon mehrfache Kopien der Desktop.ini unter Win7 aufm Desktop rumliegen gehabt x)
Was sagt "dir" in der Commandline? Die VBA Dateisystem-Tools sind generell nicht der Knaller, selbst in .NET kommt man oft nicht drumherum die Winapis zu nutzen.

 

[puri]

NTFS unterscheidet sicherlich Groß/Kleinschreibung (Einmal Name Groß geschrieben bleibt groß), nur die Windows-Dateisystemtools interessiert das nicht. Anscheinend unterscheidet hier VBA..I

 

[andy_m4]

Das mag mir bei UNIX / Linux nicht weiter verwunderlich erscheinen - aber NTFS..?

NTFS unterscheidet schon immer zwischen Groß- und Kleinschreibung.
Es unterliegt dem entsprechenden Programm oder der entsprechenden API bzw. Funktion das "windows-typisch" zu implementieren.

Beim Standard-API-Call CreateFileA zum Datei öffnen gibt es ein Flag namens FILE_FLAG_POSIX_SEMANTICS, um NTFS mitzutzeilen, ob es sich bein öffnen der Dateien wie "UNIX" oder wie "DOS/Windows" verhalten soll.

Wie das jetzt bei VBA oder WSH implementiert ist, kann ich nicht sagen. Kann mir aber nicht vorstellen, dass die da die POSIX-Semantik verwenden. ggf. müsste man das mal "tracen".
Wobei gerade der alte WSH-Kram auch einige Bugs enthält.

 

[fuyuhasugu]

Das mag mir bei UNIX / Linux nicht weiter verwunderlich erscheinen - aber NTFS..?

Absolut korrekt. Die Unterscheidung von Groß- und Kleinbuchstaben ist ja Teil der Posix-Spezifikation. Und schon Windows NT 3.x hatte einen Posix-kompatiblen Unterbau und einen rein Windows-kompatiblen (Win32). Da die meisten Programme inklusive des Windows-Explorers auf Win32 basieren, können sie natürlich überhaupt nichts mit Dateien anfangen, die sich nur in ihrer Groß- und Kleinschreibung unterscheiden. Deshalb lag diese Funktion bisher auch immer brach, ist aber seit diesem Jahr in Windows 10 optional zuschaltbar, d.h. damiterreichbar auch über das Win-Subsystem und nicht nur über rein Posix-kompatible Kommandozeilentools.

 

[alxtraxxx]

Natürlich lag die Funktion brach, overloading von Namen hat bei Dateien nich nie einen Sinn ergeben x)

 

[Vindoriel]

Hab sogar schon mehrfache Kopien der Desktop.ini unter Win7 aufm Desktop rumliegen gehabt x)

Das liegt aber daran, dass eine desktop.ini in Deinem Profilordner (unter \Desktop) ist und eine unter \Users\Public\Desktop. Darum hast Du auf dem Desktop mehrere davon.

 

[cumulonimbus8]

(So hätte ich das mit dem Desktop auch gesehen.)

Nein, NTFS beherrscht groß/klein-Schreibung definitiv nicht. Es können nicht Otto.Dat, otto.dat und Otto.dat nebeneinander existieren! Unter LINUX schon.
Was geht ist, dass es die Schreibweisen beibehält - ich kann aber nicht unmittelbar Otto.Dat in otto.dat umbenennen (mag jeder austesten.)

DIR unter CMD sollte mir die gewählte Datei Otto.Dat immer als OTTO.DAT und Otto.Dat wiedergeben. Und eigentlich sollten DIR unter VBA und FileExists sich nicht durch unterschiedliche Schreibweisen beeindrucken lassen. Es ist dennoch passiert.

@Timmey92
Ich sollte mich doch sehr wundern wenn das nicht NTFS wäre. Aber technisch hast du mich erwischt.

Diese Platte und einige andere habe ich schon über Jahre mit dem Skript bearbeitet. Ist da jüngst vom MS mal wieder was gedreht worden was so wenig wie SAM1 oder das Stoppen von Diensten laut genug verbreitet wurde?

CN8

 

[BlubbsDE]

Einfach die Beiträge nochmal in Ruhe lesen. Was Du schreibst, wird in den Beiträgen widerlegt und erklärt.

Und ein DIR in der CMD zeigt die Dateien genauso an, wie man sie geschrieben hat. Mit Klein und Großbuchstaben. OK, unter DOS würde es anders aussehen. Aber das ist hier wohl irrelevant. NTFS unterscheidet schon immer unter Klein und Großbuchstaben. Aber wie damit umgegangen wird, das liegt am Programm / Windows usw.

 

[cumulonimbus8]

Ich verzichte auf einen Screenshot…

C:\A\DownLoads>dir
 Datenträger in Laufwerk C: ist CAROLUS
 Volumeseriennummer: 226E-CC59

 Verzeichnis von C:\A\DownLoads

2018-09-20  17:16    <DIR>                       .
2018-09-20  17:16    <DIR>                       ..
2017-11-10  19:43               162 ~$NEX-~1.DOC ~$nex-8-IT-Security-Related-Requirements---PRO-003183.docx
2017-11-10  19:43               162 ~$NEX-~2.DOC ~$nex-9-Cyber-security-resilience-capabilities---PRO-003183.docx
2018-08-22  18:05               162 ~$RVEY~1.DOC ~$rvey 2018 - XXX Xxxxx xxxxxx - Header_Help_FAQ - DE version.docx
2018-09-20  17:16               360              desktop.ini
2018-03-08  09:57             2.469 CHROME~1.LNK Chrome quexs CALL.lnk
2018-03-13  12:14             1.647 FIREFO~1.LNK FireFox queXS CALL.lnk
2018-07-03  17:01       190.513.152              MOVI0000.mpg
2018-07-03  12:59        50.204.672              MOVI0001.mpg
2018-07-03  13:00        50.956.288              MOVI0002.mpg
2018-09-11  10:48                47 NICHT-~1.NOT Nicht-Sender.note
2018-09-13  20:34         3.367.905 EZ-FAL~1.PDF ez-faltblatt.pdf
2018-01-23  17:02           485.576 PEARLS~1.PDF Pearl SD2204 Fbdg.pdf
2018-08-20  17:57         3.577.172 TIERPA~1.PDF Tierpark Berlin.pdf
2018-06-15  18:39         1.293.387 TNW_LI~1.PDF tnw_liniennetz_2018_bs_umgebung.pdf
2018-08-31  11:38           312.013 201808~1.PPT 20180830_Zweite_Umfrage.pptx
2018-08-17  17:58            73.216 ZUARCH~2.XLS zu archivierende surveys(1).xls
2018-08-09  20:26         1.843.934 CNAPPL~2.XLS XX applicants 20180724 SPLIT.xlsm
2018-08-09  19:07         1.379.762 CNAPPL~1.XLS XX applicants 20180724.xlsx
2018-09-11  08:49           480.177 ADOBEA~1.ZIP AdobeAcroCleaner_DC2015.zip
2014-04-01  04:05        15.931.750 PCWGPE~1.ZIP pcwGpeditTools.zip
              20 Datei(en),    320.424.013 Bytes
               2 Verzeichnis(se), 16.792.727.552 Bytes frei

Ich sehe da eine klares Verhalten von DIR - wie ich oben angab.

CN8

 

[alxtraxxx]

Schöne Theorien aber ich hatte sagenhafte 5 Desktop.inis aufm Desktop (die sich auch nicht löschen ließen), musste die Funktion komplett abschalten dann waren sie weg Und Groß/Kleinschreibung war überall gleich. Übrigens benutzen 90% aller Windowsprogramme noch veraltete 16bit APIs, daher gehen oft Pfade > 250 Zeichen nicht obwohl das Dateisystem keine Probleme damit hat

 

[cumulonimbus8]

5 sind heftig.

Warum aber von gestern auf heute Skripte scheitern weil Daten anders zurückgegeben werden, das ist schon e9in Ding für sich.
Ich habe im Moment keine Zeit dazu, aber mich würde reizen rauszufinden ob z.B. Name As nun auch diese Unterscheidung betreibt.

CN8

 

[Vindoriel]

Schöne Theorien aber ich hatte sagenhafte 5 Desktop.inis aufm Desktop (die sich auch nicht löschen ließen), musste die Funktion komplett abschalten dann waren sie weg Und Groß/Kleinschreibung war überall gleich.

Nur dass die Theorien durch die Praxis bestätigt werden. Mache einen Rechtsklick auf die Datei, Eigenschaften und dann weißt Du, wo die herkommt.
2 sind (zusammen), wie ich schon schrieb, standardmäßig im Desktopordner vom Benutzer und im Public.

 

[fuyuhasugu]

NTFS beherrscht groß/klein-Schreibung definitiv nicht. Es können nicht Otto.Dat, otto.dat und Otto.dat nebeneinander existieren!
Wenn du den hier gelieferten Beiträgen nicht glauben willst, erklär das doch dem Hersteller des Betriebssystems:
・Per-directory case sensitivity and WSL
・Übersicht über die Dateisysteme FAT, HPFS und NTFS

Was geht ist, dass es die Schreibweisen beibehält - ich kann aber nicht unmittelbar Otto.Dat in otto.dat umbenennen.

Doch, das geht, aber eben nicht mit den herkömmlichen Windows-Mitteln, die maximal auf dem Win32-Subsystem aufbauen. Cygwin und andere Unix-Tools unter Windows NT konnten schon immer mit der Unterscheidung arbeiten, von der Erstellung von entsprechenden Dateinamen bei Dateien, die anschließend auch mit Windows-Mitteln oder anderer Software bearbeitet werden sollten, wurde aber immer abgeraten, weil eben nicht mal Windows-Explorer oder die Kommandozeile sinnvoll damit umgehen können.
Hintergrund, dass Microsoft diese Funktion jetzt doch langsam verfügbar macht, wird wohl das Windows Subsystem for Linux sein. Und da wohl 99% aller reinen Windows-Programme noch nicht damit umgehen können, ist die Funktion momentan nur auf Ordnerbasis auch für das Windows-Subsystem zuschaltbar. Für Posix bleibt es wie seit über 25 Jahren komplett nutzbar.

 

[andy_m4]

Nein, NTFS beherrscht groß/klein-Schreibung definitiv nicht.

Meine Güte. Liest Du Dir Beiträge überhaupt?

NTFS kann sehr wohl Groß- und Kleinschreibung. Wenn Du die Datei Desktop.ini anlegst, wird die auch als Desktop.ini (mit großem D) abgespeichert. Undanhängig davon wirst Du sie aber auch z.B. unter dem Namen DESKTOP.INI wieder öffnen können.

Es können nicht Otto.Dat, otto.dat und Otto.dat nebeneinander existieren!

Doch kann es. Nur wird diese Funktionalität i.d.R. nicht genutzt.
Unter meinem Beitrag ist das auch erklärt mit Link zu Microsoft. Mit der Behauptung das das nicht stimmt unterstellst Du, dass Microsoft nicht weiß was NTFS kann und was nicht. Ich würde sagen, Du lehnst Dich damit ziemlich weit aus dem Fenster. Aber eine gewisse Beratungstresistenz ist ja bei Dir nix Neues. ;-)

 

[cumulonimbus8]

Doch kann es. Nur wird diese Funktionalität i.d.R. nicht genutzt.

Wenn sie hier nicht genutzt wird dann gist sie für mich als inexistent..: »Ein Unterschied der keinen Unterschied bewirkt ist kein Unterschied.«

Mein Problem das vom vorhandenen Filesystem kommt ist nach wie vor ungelöst.
Das hat nichts mit Beratungsresistenz zu tun, das sind simple reproduzierbare Fakten.

Und CMD ist es völlig schnurzpiepe ob es eine Otto.Dat, eine OTTO.DAT oder otto.dat in hans.txt umbenennen muss - der Befhel ist immer buchstäblich der selbe: ren otto.dat hans.txt

CN8

 

[andy_m4]

Das hat nichts mit Beratungsresistenz zu tun, das sind simple reproduzierbare Fakten.

Das bezog sich auf Deine behauptung, dass NTFS nicht zwischen Groß- und Kleinschreibung unterscheidet. Was eben nicht stimmt.

Und CMD ist es völlig schnurzpiepe ob es eine Otto.Dat, eine OTTO.DAT oder otto.dat in hans.txt umbenennen muss - der Befhel ist immer buchstäblich der selbe: ren otto.dat hans.txt

Niemand hat etwas anderes behauptet.

Wenn sie hier nicht genutzt wird dann gist sie für mich als inexistent.

Na dann dürfte es ja mit Deinem ominösen Skript kein Problem geben. Allein das ist ein Problem gibt, zeigt ja das sie doch existent ist. Und da kannste Dich von mir aus auf den Kopf stellen und mit den Füßen wackeln. Nützt alles nix. Das sind reproduzierbare Fakten, wie Du so schön sagst.

Übrigens würde ich das Skript ja einfach mal posten. Vielleicht wird ja dann für irgendwen ein Fehler offenbar. Solange es nur heißt "Ich hab ein Skript was ich euch aber nicht zeige und das arbeitet fehlerhaft" wird Dir hier keiner einen ganz konkreten Hinweis liefern können.

 

[cumulonimbus8]

Das Skript das seit Jahren funktioniert? Nun denn, bitte. Allerdings habe ich anderen Ärger im Vorfeld gehabt: fehelnde Zugriffsrechte in $RECYCLE.BIN. Das mit der groß/kleinschreibung habe ich unter VBA gemerkt wohin den Code übertrug. (Ohne Worte - er lief, also ließ ich die REMs in Ruhe.)
Übergabe eines Pfades per Kontextmenü auf Ordner/Laufwerk (Letzteres eher weniger sinnig). Zweck: wo Desktop.Inis mit Icon-Angaben sind (stillschweigend vorausgesetzt) R-Attribut setzen damit der Explorer Icons auch anzeigt.

DIM WSHShell, WScriptShell, FSO, Argumente, DUMMY, QT, Meldung
SET WSHShell = WScript.CreateObject("WScript.Shell")
SET WScriptShell = WScript.CreateObject("WScript.Shell")
SET FSO = CreateObject("Scripting.FileSystemObject")

Argumente = Wscript.Arguments.Count
IF Argumente = 0 THEN WScript.Quit

QT = CHR(34)
Meldung = ""
CALL OrdnerAbsuchen (UCASE(Wscript.Arguments(0)))
WSHShell.PopUp Meldung, 5, "Bearbeitet wurden:", 64 + 0
WScript.Quit

SUB OrdnerAbsuchen(LW)
DIM Ordner
DIM OrdnerName

REM Weswegen hatte ich das nur vorgeschaltet???
REM IF FSO.GetFolder(LW & "\").SubFolders.Count > 0 THEN

  Rem Wir hatten die Root selbst vernachlässigt
  IF FSO.FileExists(LW & "\desktop.ini") THEN
   Meldung = Meldung  & vbCr & LW & "\"
   WSHShell.Run "Attrib -h +r " & QT & LW & QT, 7, FALSE
  END IF
  FOR EACH Ordner IN FSO.GetFolder(LW & "\").SubFolders
   OrdnerName = LW & "\" & Ordner.Name
   IF InStr(UCase(OrdnerName), "RECYCLER") > 0 OR _
    InStr(UCase(OrdnerName), "VOLUMEINFORMATION") > 0 OR _
     InStr(UCase(OrdnerName), "\TEMP\") > 0 THEN
    Rem C:\WINDOWS\System32\WScript.exe c:\bin\ReadOnlyOrdenrstruktur.vbs "c:\a"
   ELSE
    IF FSO.FileExists(LW & "\" & Ordner.Name & "\desktop.ini") THEN
     Meldung = Meldung  & vbCr & LW & "\" & Ordner.Name
     WSHShell.Run "Attrib -h +r " & QT & LW & "\" & Ordner.Name & QT, 7, FALSE
    END IF
   END IF
   CALL OrdnerAbsuchen(LW & "\" & Ordner.Name)
  NEXT

REM END IF

END SUB

Zeile 34 wäre die kritische.

Unter «beherrschen» verstehe ich nach wie vor im Alltag eine Wirksamkeit. NTFS ist unter WIN nicht wirksam was groß/kleinschreibung angeht. Verglichen mit Linux. Otto.Dat, otto.dat, OTTO.DAT sind einmal dasselbe und ein andermal nicht.
Und dummerweise ist das gut darin mein Skript zu sabotieren. Deswegen hoffe ich hier ja auf Ideen wie man das ohne Klimmzüge löst.
(Klimmzüge wären aus der Lamäng alle Files im Ordner auszulesen um Dateinamen zu haben die dann UCase oder LCase zum Opfer fallen um als Desktop.Ini erkannt zu werden.)

CN8

 

[cumulonimbus8]

Grummel… Knatsch… Brummel…

Ich hatte es wirklich geschafft eine ganze Reihe meiner Desktop.Inis als «Desktop.ini» zu speichern.
Einschub: wie erwähnt hatten mich Zugriffsrechte »im Mülleimer« da komplett lahmgelegt. Immerhin kennt auch WSH das On Error … womit ich nun immerhin das ganze Laufwerk abgrasen kann ohne da schon hängen zu bleiben.

Diese abhängigen VBA-Subs stellen die grundsätzliche Schaltlogik dar mit der ich erst mal ein Rückumbenennen einfädeln kann (sturköpfchen). Das Auskommentierte tut aus gewissen Gründen nicht direkt und diente nur der Sysntaxnotation.

Sub DateinanemGroßKlein()
 Debug.Print "-----------"
 OrdnerRekursiv ("e:\")
 Debug.Print "-----------"
End Sub
Sub OrdnerRekursiv(OrdnerName As String)
Dim FSO As Object
Dim Ordner As Object
Dim DatEi As Object
Dim Von As String
Dim Nach As String
 On Error GoTo Fehler
 Set FSO = CreateObject("Scripting.FileSystemObject")
 For Each Ordner In FSO.GetFolder(OrdnerName).SubFolders
  For Each DatEi In Ordner.Files
   If UCase(DatEi.Name) = "DESKTOP.INI" Then
    If DatEi.Name <> "desktop.ini" Then
     Debug.Print DatEi.Path
 '    Von = Ordner.Path & "\" & DatEi.Name
 '    Nach = Ordner.Path & "\desktop.ini"
 '    Name Von As Nach
    End If
   End If
  Next
  Call OrdnerRekursiv(Ordner.Path)
 Next
 Exit Sub
Fehler:
 Debug.Print "Rumms: " & Ordner.Path
 'Stop
 Resume Next
End Sub

Was mich nach wie vor schwerpunktmäßig ärgert ist, dass VBA und WSH grandios an Schreib/Leserechten scheitere de ich als Admin offenbar habe da ich mich dort durchaus umsehen kann.
Gibt es dafür eine Lösung..?

CN8