Bug: Dateien werden nicht an relativem Pfadnamen gesucht
Verfasst: 01.04.2018, 13:47
Ich speichere meine Bilddateien in einem Ordner (und darin enthaltenen Unterordnern), welcher im gleichen Verzeichnis wie die .ahn-Datei liegt.
Wenn ich in Ahnenblatt eine Datei einer Person zuordne, speichert er auch korrekt den absoluten Dateinamen, als auch den relativen Dateinahmen (der - stümperhafterweise - direkt nach dem Anlegen noch direkt mit dem Namen des Unterverzeichnisses beginnt, beim nochmaligem Öffnen/nach dem übernehmen dann mit einem "./").
Der Ordner mit der .ahn-Datei als auch dem Bildverzeichnis liegen bei mir in einem GDriver-Ordner, d.h. einem Ordner, der auf verschiedenen Rechnern synchronisiert ist. D.h. die Dateien haben auf verschiedenen Rechnern verschiedene absolute Pfadnamen (wie bei einem USB-Stick auch).
Wenn ich die .ahn-Datei nun auf einem anderen Rechner unter anderen absoluten Pfadnamen öffne, findet er die zugeordneten Bilder nicht mehr.
Obwohl die relativen Pfadname ja noch immer stimmen. Das Programm sucht beim Laden der .ahn-Datei die Bilddateien schlicht nicht im relativen Pfad. Das ist ein Fehler.
Beobachtungen:
Es zeigten sich verschiedene seltsame verhaltensweisen des Programms:
- Wenn ich zu einer Person eine schon hinterlegte, aber "nicht gefundene" Datei noch einmal hinterlegen möchte (von einem anderen absoluten, aber identischen relativen Pfad), dann moniert Ahnenblatt in manchen Fällen, dass die Datei schon vorhanden ist. Und zeigt diese NACH diesem Vorgang plötzlich (ohne sonstige Änderung) an
- Ich kann manchmal eine Datei mit "falschem" absoluten Pfad und korrektem relativem Pfad (die nicht gefunden wurde) noch einmal hinterlegen. Dann haben diese beiden Dateien unterschiedliche absolute Pfade und identischen relativen Pfad. Angezeigt wird aber immer nur eine Datei, je nachdem welcher absolute Pfad auf dem entspr. Rechner eben stimmt.
Die portable Version scheint erstaunlichweise noch weniger mit relativen Pfadnamen klarzukommen. Hier wird unfassbarerweise der Pfad zur exe-Datei (statt zur .ahn-Datei!) als Stammpfad bzgl. der relativen Dateiangabe genutzt. Sofern man seine Bilder nicht unter die .dll- und .ini-Dateien mischen will, werden damit faktisch nur absolute Pfadangaben erzeugt.
Die neue 3-er Beta-Version zeigt die gleichen fehler wie die aktuelle Version.
--
Dieses ganze Dateihandling scheint mir schlecht durchdacht und stümperhaft umgesetzt. Was seltsam ist, da das Datei-Feature kein Randthema ist (sondern essentiell) und das Programm doch ansonsten einen sehr guten Eindruck macht ...
Wenn ich in Ahnenblatt eine Datei einer Person zuordne, speichert er auch korrekt den absoluten Dateinamen, als auch den relativen Dateinahmen (der - stümperhafterweise - direkt nach dem Anlegen noch direkt mit dem Namen des Unterverzeichnisses beginnt, beim nochmaligem Öffnen/nach dem übernehmen dann mit einem "./").
Der Ordner mit der .ahn-Datei als auch dem Bildverzeichnis liegen bei mir in einem GDriver-Ordner, d.h. einem Ordner, der auf verschiedenen Rechnern synchronisiert ist. D.h. die Dateien haben auf verschiedenen Rechnern verschiedene absolute Pfadnamen (wie bei einem USB-Stick auch).
Wenn ich die .ahn-Datei nun auf einem anderen Rechner unter anderen absoluten Pfadnamen öffne, findet er die zugeordneten Bilder nicht mehr.
Obwohl die relativen Pfadname ja noch immer stimmen. Das Programm sucht beim Laden der .ahn-Datei die Bilddateien schlicht nicht im relativen Pfad. Das ist ein Fehler.
Beobachtungen:
Es zeigten sich verschiedene seltsame verhaltensweisen des Programms:
- Wenn ich zu einer Person eine schon hinterlegte, aber "nicht gefundene" Datei noch einmal hinterlegen möchte (von einem anderen absoluten, aber identischen relativen Pfad), dann moniert Ahnenblatt in manchen Fällen, dass die Datei schon vorhanden ist. Und zeigt diese NACH diesem Vorgang plötzlich (ohne sonstige Änderung) an
- Ich kann manchmal eine Datei mit "falschem" absoluten Pfad und korrektem relativem Pfad (die nicht gefunden wurde) noch einmal hinterlegen. Dann haben diese beiden Dateien unterschiedliche absolute Pfade und identischen relativen Pfad. Angezeigt wird aber immer nur eine Datei, je nachdem welcher absolute Pfad auf dem entspr. Rechner eben stimmt.
Die portable Version scheint erstaunlichweise noch weniger mit relativen Pfadnamen klarzukommen. Hier wird unfassbarerweise der Pfad zur exe-Datei (statt zur .ahn-Datei!) als Stammpfad bzgl. der relativen Dateiangabe genutzt. Sofern man seine Bilder nicht unter die .dll- und .ini-Dateien mischen will, werden damit faktisch nur absolute Pfadangaben erzeugt.
Die neue 3-er Beta-Version zeigt die gleichen fehler wie die aktuelle Version.
--
Dieses ganze Dateihandling scheint mir schlecht durchdacht und stümperhaft umgesetzt. Was seltsam ist, da das Datei-Feature kein Randthema ist (sondern essentiell) und das Programm doch ansonsten einen sehr guten Eindruck macht ...