Bug: Dateien werden nicht an relativem Pfadnamen gesucht

Gesperrt
Gast

Bug: Dateien werden nicht an relativem Pfadnamen gesucht

Beitrag von Gast »

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 ...
Gast

Beitrag von Gast »

Hier gibt es noch jemanden, der offensichtlich unter den Auswirkungen des Bugs zu leiden hat(te):
http://www.ahnenblattportal.de/viewtopic.php?t=6696
Benutzeravatar
Fridolin
Beiträge: 3573
Registriert: 04.01.2017, 18:32
Wohnort: Regio Rhein-Neckar

Re: Bug: Dateien werden nicht an relativem Pfadnamen gesucht

Beitrag von Fridolin »

Hallo Gast,

in deinem Post kommt mehrfach das Wort "stümperhaft" vor - da habe ich ein paarmal durchatmen müssen, da ich vor der Leistung von Dirk B., der das alles im Laufe von mehr als 15 Jahren als Hobbyprojekt programmiert hat, eine ziemliche Hochachtung habe. Ich nehme zur Kenntnis, dass du dich aber ziemlich geärgert hast.
Anonymous hat geschrieben: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 "./").
Ich nehme an, du redest von der 2.98-er Version. Ich muss zugeben, dass mir nicht so klar ist, was AB tatsächlich speichert: Ich verwende als Standard das *.ahn-Format, das sich im Quelltext nicht lesen lässt. Im Info-Tab zum Bild wird mir ein Dateipfad und ein Alternativpfad angezeigt; sie sind bei mir bei neu eingetragenen Medien gleich - keiner der beiden ist relativ.

Da wir von einem Windows-Programm reden, würde ich sagen, dass die beiden von dir beschriebenen Schreibweisen des relativen Pfads beide in Ordnung sind: der erste ("stümperhaft") ist vermutlich die schon von DOS bekannte Schreibweise (mit Backslashes für Unterordner), der zweite (mit "./" beginnend) ist unixoid und auch von HTML und WWW bekannt.
Anonymous hat geschrieben: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.
Das mit dem GDrive-Ordner ist ein interessantes Konzept. In den letzten Jahren dürfte das für einige Anwendungs-Szenarien üblich geworden sein (zumindest für fortgeschrittene und wenig ängstliche Nutzer). Ob es für Ahnenblatt aus den von dir genannten Gründen grundsätzlich überhaupt funktioniert, ist eine andere Frage. Deine Beobachtungen sprechen dagegen - auch wenn du das einen Fehler nennst, könnte man das einen nicht vorgesehenen Anwendungsfall nennen.

Ich weiß nicht, welche Probleme Dirk bewogen haben, für AB portable die relativen Pfade stillzulegen. Es leuchtet mir ebenso wie dir nicht ein, aber ich kenne die Gründe nicht. Ich gehe davon aus, dass es welche gab. Und ich würde auch denken, dass es sehr nützlich/hilfreich wäre, wenn man Ahnenblatt portable mit relativen Dateipfaden kombinieren könnte: Das wäre die schönste Art, Familiendaten mit einem "Viewer" weiterzugeben, mit dem die Leute dann sogar weiterarbeiten könnten. Du bist nicht der erste, der das erwartet.

Geben wir ruhig zu, dass Ahnenblatt ein klassisches PC-Programm ist. Nach ersten Versionen für Atari wurde es ab 2001 für Windows angeboten. Es ist typisch für ein stationär installiertes Programm entwickelt worden. Es ist nicht mulitplattformtauglich, es ist derzeit definitiv nicht multi-user-tauglich (hat keine Zugriffskontrolle), es würde nicht als Online-Software laufen, und es ist auch nach einigen internen Änderungen derzeit offensichtlich nicht uneingeschränkt tauglich für die Verwendung in Online-Netzlaufwerken. Angesichts eines derzeit kostenlosen Angebots würde ich das lieber zur Kenntnis nehmen und mich entscheiden, ob ich es so (as-is) nutzen will oder nicht - statt zu schimpfen. Es war bisher das ideale Einsteiger-Programm mit einer übersichtlichen, zweckmäßigen Grundfunktionalität. Ähnlich wie wordpad als Textverarbeitung oder paint.net als Grafikprogramm. Und der Bezug zur exe bei der Portable-Version dürfte fürs Brennen auf CD ganz nützlich gewesen sein (bloß: Ich kann heute nicht mehr jedem eine CD weitergeben mangels Laufwerk).

Derzeit ist in mehrfacher Hinsicht ein großer Sprung geplant: Ahnenblatt wird mit der kommenden Version in seiner Funktionalität erheblich aufgewertet. Und es wird kostenpflichtig werden. Es ist naheliegend, dass Dirk sich über die Unterstützung von verschiedenen Nutzungsszenarien in näherer Zukunft noch einmal Gedanken machen sollte, wenn er durchstarten will. Also: multiuser-Tauglichkeit in Cloud-Shares und Pfadbezug der Medien. Das wären schon ziemliche Herausforderungen angesichts der Historie des Programms. Multiplatform ist vermutlich sowieso auszuschließen - das schafft man nicht allein.

Vielleicht kannst du die Sache auch aus diesem Blickwinkel sehen - statt (aus meiner Sicht) ziemlich von oben herab zu poltern, weil deine Arbeitsweise nicht problemlos unterstützt wird.

Übrigens nutze ich Ahnenblatt mit Daten auf einem NAS - da dieses mit festem Laufwerksbuchstaben eingebunden ist, kann ich das problemlos verwenden. Und wenn ich offline bin (also unterwegs), habe ich die entsprechenden Dateien als offline-Kopie eingebunden und synchronisiere später wieder. Das ist längst nicht so flexibel wie deine Vorstellung, aber vielleicht bringt es dich auf alternative Ideen.

Gruß,
Frido
Aktuell Win10-64 pro 2004, Ahnenblatt 3.46 - Daten via NAS, Programm lokal

Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen! :book:
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
RandolfHermann
Beiträge: 2
Registriert: 01.04.2018, 13:03

Beitrag von RandolfHermann »

Hallo Frido,

Ich war der "Gast" oben und bedanke mich für deine ausführliche und besonnene Antwort.

Auch ich habe große Achtung vor der Leistung von Dirk. Auch davor, dass er das Programm (jahrelang) kostenfrei weitegegeben hat und noch immer gibt.

Doch vieles deutet darauf hin, dass diese Dateieinbindungssache in vielerlei Hinsicht eher so ein ungeliebtes Kind des Programmierers ist. Ja, solche Pfad- und Dialoggeschichten sind lästig in der Programmierung, aber wenn man sauber an die Sache herangeht, sind sie auch sauber zu lösen. Ich kenne das aus eigener Erfahrung. Nun gut, genug gemosert ...

Ich habe übrigens kein Problem damit, für das Programm zu zahlen. Ich hätte das auch (freiwillig) für die 2.x-Version und werde mir die 3-er Version auch kaufen - Wenn sie denn bildermäßig funktioniert (was sie im Moment ja auch nicht tut).

Da du ja schon länger hier unterwegs bist, kannst du mir vielleicht sagen, wie groß die Wahrscheinlichkeit ist, dass Dirk erkannte Fehler beseitigt oder auch, wo man ihm den Fehler direkt melden kann?!


Was die Nutzung über so ein Online-Drive angeht: Diese Cloud-Sachen sind im Grunde genau die Lösung für "ältere" Programme, da sie solche Dateisynchronisationen transparent abwickeln.
Solange man nicht auf die Idee kommt, Instanzen von AB zeitparallel zu öffnen, sollte es keine Probleme geben.

Ich bearbeite den Stammbaum auf meinem PC und nehme gelegentlich ein Notebook mit zu meinen Verwandten, um dort Sachen nachzutragen oder Personenbestimmungen auf den Bildern zu machen. Auch könnte man den Ordner "freigeben" und Anverwandte können die Datei (inkl. Bilder) auf dem eigenen PC betrachten/bearbeiten. Manche Cloudspeicher kennen ja sogar Versionierung. Aber probiert habe ich das noch nicht ...
Benutzeravatar
Fridolin
Beiträge: 3573
Registriert: 04.01.2017, 18:32
Wohnort: Regio Rhein-Neckar

Beitrag von Fridolin »

Hallo Randolf,
RandolfHermann hat geschrieben: Da du ja schon länger hier unterwegs bist, kannst du mir vielleicht sagen, wie groß die Wahrscheinlichkeit ist, dass Dirk erkannte Fehler beseitigt oder auch, wo man ihm den Fehler direkt melden kann?!
Wenn knapp anderthalb Jahre für dich schon unter "schon länger" fallen, kann ich eine Antwort geben:

1. Im Forum gibt es eine Wunsch- und eine Fehlerliste; die Trennung ist aus meiner Sicht unscharf. In deinem Fall bin ich nach wie vor der Meinung, dass man unterschiedlicher Ansicht sein kann, ob es da einen (objektiven) Fehler gibt, oder nur in einem bestimmten Anwendungsfall ein unerwünschtes Verhalten. Solche Meldungen nimmt sich Dirk meiner noch relativ kurzen Erfahrung nach gruppenweise vor - wo er sowieso gerade dran ist, bearbeitet er sie gleich mit.

2. Im Programm wird unter "? > Info" eine eMail-Adresse genannt, an die man direkt Fehler schicken kann; allerdings ist das Forum genau zu dem Zweck gegründet worden, dass man solche Fehlermeldungen teilen und vorsortieren kann. Im Forum http://www.ahnenblattportal.de/viewforum.php?f=7 gibt es entsprechende Listen, die von den Admins einigermaßen auf dem Laufenden gehalten werden. Dirk liest immer wieder mit - aber weder auf dem einen noch auf dem anderen Weg kann man damit rechnen, dass man von ihm über eine Korrektur hinaus auch jedes Mal eine Rückmeldung bekommt - das übersteigt anscheinend seine Kapazitäten.
RandolfHermann hat geschrieben: Was die Nutzung über so ein Online-Drive angeht: Diese Cloud-Sachen sind im Grunde genau die Lösung für "ältere" Programme, da sie solche Dateisynchronisationen transparent abwickeln.
Solange man nicht auf die Idee kommt, Instanzen von AB zeitparallel zu öffnen, sollte es keine Probleme geben.
Außer der Sache mit den wechsenden Pfaden durch wechselnde Laufwerksbuchstaben (hat man mit einem Stick evtl. auch, gibt aber dieselben Probleme).

Weiterhin viel Spaß mit dem Programm - über die gegebenen Hinweise hinaus fällt mir nichts mehr ein zu den genannten Problemen.

Frido
Aktuell Win10-64 pro 2004, Ahnenblatt 3.46 - Daten via NAS, Programm lokal

Empfehlung: Für die neue Version 3.x alle relevanten Handbücher lesen! :book:
(es gibt das Benutzerhandbuch und mehrere Themen-Specials!)
Gesperrt