Hallo,
wenn ich unter Windows 8.1 in einem beliebigen Programm den
Öfnnen-Dialog aufrufe und das Verzeichniss "C:\Windows\System32" wähle,
dann ist die dargestellte Liste der Dateien nicht vollständig. Es fehlen
bestimmte Dateien, die beim Aufruf des besagten Verzeichnisses mit dem
gewöhnlichen Explorer vorhanden sind.
Vorwiegend – aber nicht ausschließlich – handelt es sich bei den
fehlenden Dateien um Anwendungen oder Dienste die laufen, also im
Task-Manager aufgelistet sind. Die fehlenden Datein sind weder mit dem
Attribut "versteckt" markiert, noch handelt es sich um geschützte
Systemdateien.
Kennt jemand dieses Phänomen oder kann es bestätigen, da mir das Ganze
doch etwas seltsam vorkommt.
Vielen Dank und beste Grüße,
Roland.
Anbei zwei Screenshots um das Problem zu verdeutlichen: Unter anderem
die Datei "dasHost.exe" ist nur im Explorer sichtbar, nicht jedoch im
Öffnen-Dialog. Beide Listen sind nach Namen sortiert.
Anmerkung: Wie mir so eben beim Betrachten der Screenshots auffällt,
stimmen nicht einmal das Änderungsdatum sowie die Dateigröße der in
beiden Listen vorhandenen Dateien zusammen!
Guten Abend,
lass mich raten - du hast ein 64 Bit Windows, aber dein Notepad++, mit
dem du versuchst zu öffnen ist 32 Bit?
Falls ja: Ich kann jetzt keine fachlich korrekte Erklärung liefern, aber
soweit ich mich erinnere, gibt es eine Art zweites System32 für 32
Bit-Anwendungen. Korrigiert mich.
Ich bin da drauf gestoßen, als ich mal die Hosts Datei mit NPP
bearbeiten wollte.
Kannst ja mal probieren, die Datei mit dem Windows Notepad, was AFAIK 64
Bit ist, zu öffnen.
Korrigiert mich, wenn ich falsch liege.
Grüße
Vielen Dank für die rasche Antwort, Du hast absolut recht!
Im Öffnen-Dialog von 64-Bit-Programmen sind alle Dateien des
System32-Ordners wie im Explorer aufgelistet und haben dieselbe Größe,
wärend im Öffnen-Dialog von 32-Bit-Programmen Dateien fehlen und
vorhandene Dateien in Größe und Änderungsdatum abweichen.
Sehr interessant, da werden also 32-Bit-Programmen andere Systemdateien
zur Auswahl im Öffnen/Speichern-Dialog angeboten. Gut, macht sicher
Sinn, da die Programme selbst ja auch die 32-Bit-Version der
Systemdateien zum Betrieb benötigen. Nur hätte man das wohl besser mit
zwei unterschiedlichen Ordnern lösen sollen, da unterschiedlichen Datein
im scheinbar selben Pfad dann doch etwas verwirren.
Auf jeden fall Danke.
Roland schrieb:> wärend im Öffnen-Dialog von 32-Bit-Programmen Dateien fehlen und> vorhandene Dateien in Größe und Änderungsdatum abweichen.
Ja, denn das 32-Bit-Programm greift auf \Windows\SysWow64 statt auf
\Windows\System32 zu. Das wird von Windows so gehandhabt, um zu
vermeiden, daß ein 32-Bit-Prozess die für ihn unpassenden Systemdateien
verwendet.
Ein 32-Bit-Prozess kann keine 64-Bit-DLLs verwenden.
Okay, wie vermutet macht das natülich Sinn. Nur dieses "Umleiten" hätte
man besser verbergen können, sodass wirklich nur programminterne
Zugriffe auf "System32" zu "SysWow64" weitergeleitet werden, wärend die
Benutzerschnittstelle àla Öffnen/Speichern-Dialog (zumindest für die
standard Windows-API-Dialoge) davon verschont bleibt.
Tja, MS hat sich bei der Erweiterung von 32 auf 64 Bit äußerste Mühe
gegeben, so ziemlich alles so schlecht und unlogisch wie möglich zu
machen; das ist ein Teil davon.
OS X konnte auf 64-Bit Hardware mit einem 32-Bit-Kernel laufen und
64-Bit-Prozesse ausführen ... das hatte dann zwar Performanceeinbußen
zur Folge, die aber recht gering waren, und den riesigen Vorteil, daß
nicht sämtliche Devicetreiber auf einen Schlag durch neue ersetzt werden
mussten.
bis jetzt hat mich noch jedes Windows hie und da angelogen was
vorhandene Dateien angeht.
Es geht um Userdateien (anders als o.g.) auf lokalen oder Netzlaufwerke.
Zum einen setzt man die Explorer-Dateisuche an, wil man den (in d.
Firma) langen Pfad nicht mehr genau weiss - die Suche kommt jedoch zu
leerem Ergebnis, also nix gefunden.
Das kann nicht sein denkt man und wühlt sich händisch (per
zeitaufwändige Irrwege über falsche Pfade) bis man doch endlich zur
Datei kommt (sie wird im Explorer gelistet). Man öffnet die Datei sogar
(das lokale OS greift aktiv über den Pfad zur Datei).
Ungläubig setzt man die Suche wie zu Beginn nochmal in gange (nach
prüfen des Startpfades, des Suchkriteriums, auch in einem sep.neu
geöffneten Explorerfenster). Suchergebnis null.
IT-Abteilung kann das nicht erklären.
Vertrauen in Windows angeknackst.
Frust.
alle Windows (Explorer) lügen hie und da schrieb:> IT-Abteilung kann das nicht erklären.> Vertrauen in Windows angeknackst.
klingt sehr nach Suchindex. Auch der geht bei Netzlaufwerken. Wenn die
Daten nicht indiziert sind und er sich darauf verlässt dann findest er
halt nichts.
Aber der Suchindex hat auch Vorteile, wenn er richtig arbeitet. Man kann
in PDFs/Word/Excel (auch TIF) Datei nach Textinhalt suchen. Was man mit
einer einfache suche nicht hinbekommt.
Rufus Τ. F. schrieb:> OS X konnte auf 64-Bit Hardware mit einem 32-Bit-Kernel laufen und> 64-Bit-Prozesse ausführen ...
Die Macs mit Intel Prozessoren kamen IIRC erst nach der Einführung von
AMDs 64 Bit Erweiterung heraus. Da dürfte auch der 32-Bit Kern schon
rudimentäre Unterstützung für haben. Ganz ohne würde IMHO kein
Kontextwechsel funktionieren.
OeffnenDialog.png
(62 KB)
Explorer.png
(64 KB)
