AW: [Allegro] Relative Pfade

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Fischer,

>> ??? Avanti sucht im Verzeichnis der Datenbank, im virtuellen 
>> Aufrufpfad (deprecated)
> 
> Was heißt hier "deprecated"?

Weil damit der Client dem Server einen Pfad mitteilt, von
dem der Client strenggenommen nichts wissen darf. Hierbei
(und weil Avanti den Upload serverseitig gespeicherter Dateien
erlaubt, z.B. /etc/password) kommt mir regelmaessig die Galle hoch.


>> und in seinem Konfigurationsverzeichnis (etc ?).
>> Die virtuellen Aufrufpfade lassen sich in neueren Versionen 
>> relativ (zum etc-Verzeichnis?) angeben.
> 
> Lässt sich das "(zum etc-Verzeichnis?)" klären?

Schauen Sie in die Sourcen ;-). Ich finde leider keine Korrespondenz
oder Dokumentation, die darauf naeher eingeht.


>>> - Z39.50 sucht in seinem Hilfsverzeichnis und dem 
>>> Avanti-Programmverzeichnis
>> z39.50 benutzt keine Parameterdateien, uebergibt an avanti 
>> auch keinen virtuellen Aufrufpfad, d.h. Sie sind auf das 
>> Datenverzeichnis und das Avanti-"Programm"-Verzeichnis beschraenkt.
> 
> Stimmt das so? Z39.50 hat ein etc-Verzeichnis, dort liegen aber nur
> Konfigurationen, und ein Verzeichnis "share/z3950/" worin laut Dokumentation
> die "Export-Parameterdateien für Avanti" liegen.
> Dass das Z39.50-Target dann noch einigen Unsinn mit der Erkennung der
> Konfiguration anstellt, steht auf einem andern Blatt.

Ich habe vorhin in einer avanti-Logdatei nachgesehen und keinen
virtuellen Aufrufpfad in den vom ZTarget erzeugten Jobs gesehen.
(Und die Parameterdateien sind definitiv fuer avanti, nicht fuers
ZTarget). Fuer das ZTarget kenne ich auch keine
Konfigurationseinstellung, um den Aufrufpfad zu setzen


>>> (Symbolische Links helfen auf meinem Windows-System 
>>> allerdings nicht.)
>  
>> (gibt es unter NTFS aber auch)
> Meine Sie fsutil?

Nein. NTFS kennt Hardlinks und soweit ich weiss auch noch neben
.lnk-Dateien "tiefer" realsierte Softlinks. [Beim Feature-Vergleich
von Backup-Programmen wird manchmal erwaehnt, ob solches "gekonnt"
wird]


>> D.h. strenggenommen benoetigen Sie derzeit zwei Kopien Ihrer 
>> Parameterdatei, eine im zentralen 
>> Classico-Programmverzeichnis fuer die ueber das Dateisystem 
>> zugreifenden Clients PRESTO etc. und a99.
>> Und eine im avanti-Zentralverzeichnis fuer die 
>> client-server-Anwendung.
>> Ist das wirklich ein so grosses Verwaltungsproblem?
> 
> Was heißt "groß"? Schon zwei Versionen derselben Datei können Verwirrung
> stiften, wenn man sich nicht immer klar macht, welche denn gerade wirkt. Das
> Allegro-Verzeichnis selbst ist so unübersichtlich (aktuell bei mir 511
> Objekte), dass ich es am liebsten gar nicht für eigene Dateien benutzen
> würde.  Und da es hier um ca. 100 Dateien geht, die ich gerne noch nach
> verschiedenen Funktionen aufteilen würde, wäre diese relative Adressierung
> eine große Hilfe. Und wenn Avanti das bei den virtuellen Aufrufpfaden kann,
> warum dann nicht zumindest A99?

Das meiste sehe ich auch so. Mir fehlt oft eine Zwischenebene zwischen
Arbeitsverzeichnis (auf das ich wenig Einfluss habe, da es dem Benutzer
"gehoert"), Datenverzeichnis und Programmverzeichnis: Bei Importen und
mehrstufigen Exporten z.B. benoetige ich u.U. fuer die (Ziel)datenbank
angepasste Parameter (die also nicht im Programmverzeichnis liegen
duerfen), wenn ich die unkonvertierten Fremddaten und alle
Zwischenergebnisse nicht ins Datenverzeichnis ballern will, ist da eine
echte Luecke.

Manchmal braucht man fuer eine gewisse Funktionalitaet ein Buendel von
Parameter- und Flex-Dateien etc., da waere es fuer die Pflege ganz
schoen nuetzlich, die - getrennt von allen anderen Dateien - in einem
eigenen Verzeichnis zusammenhalten zu koennen (das duerften gerne
relative oder ausschliesslich untergeordnete Verzeichnisse zum
Programmverzeichnis sein).

Aber das geht natuerlich alles nicht.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFK3dXhKFJT0F1FsoRAgs+AJ9Vi5zokeeGz+qLlREuAGwr5YIwrwCfUcvS
9la4APGJS8On6W6RG59hX2w=
=EEok
-----END PGP SIGNATURE-----