AW: Problembehebung durch Ursachenerforschung: Diagnose
Hallo Eike,
wenn es den Schlüssel nicht gibt, kann ich ihn nicht testen. Ich vermute(!), Joachim schreibt jetzt nur dann den Pfad in die Registry, wenn der Pfad verändert wurde:
HKEY_CURRENT_USER\Software\Joachim Koopmann Software\FixFoto\Options\ThumbNails
HKEY_CURRENT_USER\Software\Joachim Koopmann Software\FixFoto\Options\ProviderPath
HKEY_CURRENT_USER\Software\Joachim Koopmann Software\FixFoto\Computer\eMailDir
Wobei gilt: Ist kein Pfad angegeben, dann Datenpfad für Datenbank und Datenpfad\tempmail. Somit ist die Basis der Datenpfad. Wenn da nichts geht, geht idR auch darunter nichts, da die Rechte vom höheren Pfad geerbt werden. Ist das anders, hat es einmal Probleme mit den Rechten gegeben.
Ist mir auch schon passiert, als ich versuchte ein Benutzerkonto von einem anderen abzugrenzen und den Zugriff regelte und später wieder freigab. Da kann schon mal was schief gehen und Teile sind nicht mehr adressierbar. Musste teilweise die Verzeichnis/Datei-Rechte reparieren, teilweise haben sie sich wieder selbst repariert (unter Vista). Manchmal scheint im ActiveDirectory der Wurm drin zu sein.
Ich habe am Schreibtest übrigens nur geändert, dass er bei Leerzeichenfolge vorher mit Meldung aussteigt. Nichts weltbewegendes.
Im Folgenden wird so vorgegangen:
An Pfad temporären Dateinamen anhängen, der mit fso erzeugt wurde:
Datei erzeugen -> Fehler? -> Ausgabe der Fehlermeldung des OS (Err.Description)
Datei schreiben und schließen -> Fehler? -> Ausgabe der Fehlermeldung des OS
Datei wieder löschen -> Fehler? -> Ausgabe der Fehlermeldung des OS
Keine Fehlermeldung -> Ok
Die Routine steigt also aus, wenn: Keine Rechte vorliegen, der Pfad nicht existiert, sonstige mögliche Fehler.
@Micha
Mir ist derzeit keine Möglichkeit bekannt 32-Bit FF von 64-Bit zu unterscheiden. Weder über Registry, Dateien oder FF selbst.
Hallo Eike,
wenn es den Schlüssel nicht gibt, kann ich ihn nicht testen. Ich vermute(!), Joachim schreibt jetzt nur dann den Pfad in die Registry, wenn der Pfad verändert wurde:
HKEY_CURRENT_USER\Software\Joachim Koopmann Software\FixFoto\Options\ThumbNails
HKEY_CURRENT_USER\Software\Joachim Koopmann Software\FixFoto\Options\ProviderPath
HKEY_CURRENT_USER\Software\Joachim Koopmann Software\FixFoto\Computer\eMailDir
Wobei gilt: Ist kein Pfad angegeben, dann Datenpfad für Datenbank und Datenpfad\tempmail. Somit ist die Basis der Datenpfad. Wenn da nichts geht, geht idR auch darunter nichts, da die Rechte vom höheren Pfad geerbt werden. Ist das anders, hat es einmal Probleme mit den Rechten gegeben.
Ist mir auch schon passiert, als ich versuchte ein Benutzerkonto von einem anderen abzugrenzen und den Zugriff regelte und später wieder freigab. Da kann schon mal was schief gehen und Teile sind nicht mehr adressierbar. Musste teilweise die Verzeichnis/Datei-Rechte reparieren, teilweise haben sie sich wieder selbst repariert (unter Vista). Manchmal scheint im ActiveDirectory der Wurm drin zu sein.
Ich habe am Schreibtest übrigens nur geändert, dass er bei Leerzeichenfolge vorher mit Meldung aussteigt. Nichts weltbewegendes.
Im Folgenden wird so vorgegangen:
An Pfad temporären Dateinamen anhängen, der mit fso erzeugt wurde:
Datei erzeugen -> Fehler? -> Ausgabe der Fehlermeldung des OS (Err.Description)
Datei schreiben und schließen -> Fehler? -> Ausgabe der Fehlermeldung des OS
Datei wieder löschen -> Fehler? -> Ausgabe der Fehlermeldung des OS
Keine Fehlermeldung -> Ok
Die Routine steigt also aus, wenn: Keine Rechte vorliegen, der Pfad nicht existiert, sonstige mögliche Fehler.
@Micha
Mir ist derzeit keine Möglichkeit bekannt 32-Bit FF von 64-Bit zu unterscheiden. Weder über Registry, Dateien oder FF selbst.