Dateien fehlen im Öffnen-Dialog

[Roland (Gast)]

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!

[Peter K. (peterka2000)]

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

[Roland (Gast)]

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.

[Rufus Τ. F. (rufus)]

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.

[Roland (Gast)]

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.

[Rufus Τ. F. (rufus)]

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.

[alle Windows (Explorer) lügen hie und da (Gast)]

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.

[Peter II (Gast)]

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.

[Jim M. (turboj)]

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.

[Rufus Τ. F. (rufus)]

Kernel != Kern.