2.04: Softlinks
Angela Schmidt
|> In article <1992Feb6.1...@rz.uni-karlsruhe.de> Ang...@rz.uni-karlsruhe.de writes:
|> >Der Bug ist die Definition der Softlinks. Was willst Du daran fixen???
|>
|> Huch? Ist das ein offener Glaubenskrieg? Nadenn, also;-) Nieder mit
|> hardlinks ;-)) Ich bin ein absoluter Fan von symlinks, also musst Du Dein
|> Statement schon ein bischen naeher erleutern damit wir ueber was Konkretes
|> diskutieren koennen.
|>
Du willst die einzigen momentan funktionierenden Links niedermachen? Tsst.
Meinetwegen... Ich koennte Dir ein Programm schreiben, das alle auf Deiner
Platte vorhandenen Hardlinks entfernt. ;-)
Fuer meine pattern.library ist u.a. auch MatchFirst()/MatchNext()/MatchEnd()
geplant - da muss man sich mit sowas auch mal aus Programmiererperspektive
auseinandersetzen. Du als Anwender kannst leicht sagen, her mit den Softlinks.
Also, hier mal ein paar Probleme, ueber die Du zwangslaeufig stolpern wirst,
wenn Du als Programmierer Softlinks unterstuetzen willst. Und bevor hier
jetzt Bemerkungen kommen wie: "ProgrammXYZ unterstuetzt Softlinks aber
korrekt - also muss es gehen", moechte ich noch anmerken, dass diejenigen,
die Softlinks unterstuetzen und keine Probleme bekommen haben, sich eben nie
richtig damit auseinandergesetzt haben.
1) Du weisst ja, dass Du - wenn Du einen Softlink aufloesen willst - eine
Fehlermeldung bekommst: ERROR_IS_SOFT_LINK. Dann musst Du die Sache mit
ReadLink() aufloesen und bekommst einen Ersatz-Pfadnamen. Normalerweise
scheint das auch ganz gut zu funktionieren. Eine erste Unschoenheit, die
sich wohl nicht fixen laesst, sind Links auf z.B. Disketten. Sieht Du das
Problem? Ein Objekt laesst sich nicht mehr eindeutig festlegen. Du kannst
ja zwei Disketten mit demselben Namen (z.B. "Empty") haben, auf denen
zufaellig zwei Files mit den gleichen Namen vorhanden sind. Die Files an
sich sind jedoch ziemlich verschieden. Der Softlink ist jetzt nicht mehr
eindeutig!
2) Bei der Erzeugung eines Softlinks kannst Du den Destination-Pfad ja
durchaus relativ zum aktuellen Pfadnamen angeben. Dein CurrentDir ist also
z.B. "BLUBB:dir1" und Du willst einen Softlink von "BLA:SoftLink" nach
"file1" erzeugen. Also machst Du "MakeLink BLA:SoftLink file1". Tja, und
wenn Du nun im Verzeichnis "LABER:dir2" stehst und Dir "BLA:SoftLink" ansehen
willst, klappt das nicht so ganz, weil naemlich in "LABER:dir2" kein File
namens "file1" existiert - und falls es doch existiert, hat es sicherlich
nicht denselben Inhalt wie "BLUBB:dir1/file1".
Und das ist der von mir angesprochene Punkt, der an der Definition der
Softlinks noch nicht so ganz geloest ist. Es muesste in dem Softlink noch
irgendwie klargestellt werden, von welchem Pfad ausgehend dieser erzeugt
wurde. Nur so laesst sich dieses Problem umgehen. Dazu ist in der bisherigen
Definition jedoch noch kein Raum.
Drum: BITTE LASST DIE FINGER VON SOFTLINKS, damit Randell das noch einbauen
kann!
3) Eine lustige weitere Alternative sind Softlinks auf multiple Assigns.
ReadLink() kommt damit einfach noch nicht zurecht. Statt saemtliche
Verzeichnisse abzugrasen, hoert es nach dem ersten auf. Aber das laesst sich
natuerlich auch fixen, ohne etwas an der Definition zu aendern.
--
V v Greetings,
@/@@=\ Angela
00 &=-
oOoO_/` \\_ Angela Schmidt (IRC: Nessy)
\ /&\ Internet: Ang...@rz.uni-karlsruhe.de | Amiga //
|>O<| S_ASc...@iravcl.ira.uka.de | 1000 // the
/ \_/\/\/v_ Voice: +49 731 712316 (10am to 9pm) or | \\ // original
/____________\ +49 721 6904-263 (12am to 11pm) MET | \X/ Amiga
Markus Wild
>Meinetwegen... Ich koennte Dir ein Programm schreiben, das alle auf Deiner
>Platte vorhandenen Hardlinks entfernt. ;-)
Was ja eine wirklich praktische, alltaegliche Anwendung der Links ist..
Ich *weiss*, dass man mit Directory-Loop ueber das Parent Dir den
Link identifizieren kann, aber das ist schlicht unzumutbar, wenn Du nicht
so Radikaltouren wie Du oben erwaehnt hast, vor hast.
>auseinandersetzen. Du als Anwender kannst leicht sagen, her mit den Softlinks.
Nuja, als nur-Anwender moecht ich mich denn doch auch nicht bezeichnen,
schliesslich hab ich den Name-Expander fuer meine Lib machen muessen.
>korrekt - also muss es gehen", moechte ich noch anmerken, dass diejenigen,
>die Softlinks unterstuetzen und keine Probleme bekommen haben, sich eben nie
>richtig damit auseinandergesetzt haben.
Nana... Deine Erfahrung ist ja wohl nicht das einzige und Gelbe vom
Ei, oder? Empfinde ich als ziemliche Unterstellung und Zumutung an all
jene, die sich neben Dir damit befasst haben.
>1) Du weisst ja, dass Du - wenn Du einen Softlink aufloesen willst - eine
>Fehlermeldung bekommst: ERROR_IS_SOFT_LINK. Dann musst Du die Sache mit
>ReadLink() aufloesen und bekommst einen Ersatz-Pfadnamen. Normalerweise
Das ist im Grundsatz zwar richtig, nur darfst Du nicht default-maessig
den ganzen Pfad ersetzen, sondern immer nur die letzte Komponente. Die
einzige Ausname davon ist, wenn der Link-Inhalt selber absolut ist.
>scheint das auch ganz gut zu funktionieren. Eine erste Unschoenheit, die
>sich wohl nicht fixen laesst, sind Links auf z.B. Disketten. Sieht Du das
Naja, also wer so perverse Sachen macht ist wohl selber schuld. Wenn ich
in Unix einen Symlink auf ein Objekt mache das auf einem Floppy-FS ist,
dann stellt sich genau das gleiche Problem, sowas macht man einfach nicht
(ausser Du willst zB ein df0-c dir auf der hd, dann ist wiederum erwuenscht,
dass sich der Link jedem eingelegtem Volume anpasst).
>Problem? Ein Objekt laesst sich nicht mehr eindeutig festlegen. Du kannst
Was ja grade ein Vorteil ist von symlinks, dass sie nur Namen-gebunden,
aber nicht Objekt-gebunden sind.
>2) Bei der Erzeugung eines Softlinks kannst Du den Destination-Pfad ja
>durchaus relativ zum aktuellen Pfadnamen angeben. Dein CurrentDir ist also
>z.B. "BLUBB:dir1" und Du willst einen Softlink von "BLA:SoftLink" nach
> ls -l blupp:dir1
........... file1 -> bla:softlink
oder
ls -l bla:
........... softlink -> blupp:dir1/file1
??
>"file1" erzeugen. Also machst Du "MakeLink BLA:SoftLink file1". Tja, und
Ich vermute jetzt mal, Du meinst den zweiten Fall, aber ohne den
expliziten Pfad. Da kann ich nur sagen, selber schuld. Ist ja klar, dass
das nicht eindeutig ist. Wenn ich unter Unix
ln -s gugus /usr/local/bin/brabel
mache, muss ich mich auch nicht wundern, dass ich mit /usr/local/bin/brabel
gugus nur erreichen kann, wenn ich in diesem Directory bin. Das empfinde
ich nun wirklich nicht als Bug, sondern als Frage, ob der User begriffen
hat, was ein symlink ist oder nicht.
>Und das ist der von mir angesprochene Punkt, der an der Definition der
>Softlinks noch nicht so ganz geloest ist. Es muesste in dem Softlink noch
>irgendwie klargestellt werden, von welchem Pfad ausgehend dieser erzeugt
>wurde. Nur so laesst sich dieses Problem umgehen. Dazu ist in der bisherigen
>Definition jedoch noch kein Raum.
Kein Problem, wer das umbedingt WILL (ich auf keinen Fall!), der kann das
in den MakeLink Befehl einbauen. Mach einfach ein NameFromLock auf
den Parentlock und mache grundsaetzlich alle Links absolut, damit hast
Du den User vergewaltigt das zu machen, was Du meinst, dass er es eh
machen will. Finde ich nicht gut.
>Drum: BITTE LASST DIE FINGER VON SOFTLINKS, damit Randell das noch einbauen
>kann!
Hilfe, nein...., wehe er baut sowas ein ;-) Wenn er die RAM: repariert und
ein lstat() einbaut, bin ich mit diesen Links so wie sie sind vollends
zufrieden.
>3) Eine lustige weitere Alternative sind Softlinks auf multiple Assigns.
Jo klar, man kann's auch bunt treiben. Ich stand vor der Alternative, entweder
einen Path-Expander zu machen, der beliebige Level zuruecktracken kann, um
das zu unterstuetzen, oder es sein zu lassen. Ich hab mich fuer's letztere
entschieden, und bereue es bisher eigentlich nicht.
>ReadLink() kommt damit einfach noch nicht zurecht. Statt saemtliche
Ausserdem kann da ReadLink() ja wohl GAR nix dafuer, das liest einfach
brav aus, was der `Wert' des Links ist, die Interpretation ist dann dem
Aufrufer ueberlassen. ReadLink() ist eine 1:1 Abbildung auf das READ_LINK
Packet, und Du wirst ja wohl nicht sagen, dass das Filesystem beginnen soll,
sich mit Assigns herumzuschlagen ?!?!
Nix fuer ungut ;-))
-Markus
--
Markus M. Wild - wi...@nessie.cs.id.ethz.ch | wi...@amiga.physik.unizh.ch
Q: How many IBM cpu's does it take to do a logical right shift?
A: 33. 1 to hold the bits and 32 to push the register.
Bernhard Moellemann
>>naemlich in der naechsten Release fixen. Wenn Du jetzt die alte Definition
>>von SoftLinks festklopfst und in Deinen und anderen Sachen verwendenst
>>bindest Du ihm die Haende und es wird ewig bei einem Klump bleiben.
>>
>>Lass doch bitte die Finger von SoftLinks oder brauchst Du sie _so_ dringend?
>>(es gibt doch sicher sowas wie ginclude: ...)
>
>Also erstens finde ich gar nicht, dass die jetztige Implementation ein Klump
Ich schrieb von der Definition, die ist naemlich, wie Du zugibst, noch nicht ok.
>ist, sie ist nur noch nicht vollstaendig. Ich finds eher ein Fehler, dass
>es ueberhaupt hardlinks hat, und dass die dann auch noch freigegeben wurden
>ist der groesste Skandal. Das einzige wirkliche Problem ist im Moment, dass
Was hast Du gegen HardLinks? Einzig schade ist, dass nicht die _konsequente_
Methode benutzt wurde: Alle Verweise auf das File sind identisch. _Dann_
tritt das Problem naemlich auch nicht auf!
>es keinen lstat() entsprechenden Befehl gibt. Dies koennte man allerdings
>problemlos mit einem weiteren Access-Mode fuer Lock() fixen, kein Problem
Ausser Backup-Programme geht es doch nun wirklich _niemanden_ etwas an, welcher
Verweis auf das File zuerst da war. Da fehlt noch etwas in Richtung Date und
Comment konsequent behandeln.
>fuer Randell. Du hast bei Deinem Bezug auf Randell leider nur den einen
>Teil seiner Msg erwaehnt, naemlich dass er symlinks reparieren will. Er hat
>in der genau gleichen Msg auch noch gesagt, dass er unter Umstaenden aber
>die Dinger auch in hohem Bogen wieder aus DOS rauswirft wenn er's nicht
>reparieren kann. Und genau >DAS< will ich verhindern. Symlinks sind brauchbar
>und enorm nuetzlich, auch jetzt schon. Und genau deshalb brauche ich sie
>und stehe auch fuer deren Gebrauch ein.
Ich hab auch nix gegen SoftLinks, im Gegenteil. Aber lass Randell doch die
Chance es vernuenftig zu machen! Wenn Du jetzt die alte Definition verwendest
und das auch noch genuegend andere tun, _kann_ Randell es nicht mehr aendern.
Bernhard
#8-)#
Bernhard Moellemann <spare space> Chairman of the Nessy-Fan-Club //
internet=moell...@rz.uni-karlsruhe.de FIDO=2:241/7506.42 IRC=ZZA //
nessynet=008 Lifenet=77:7700/11.42 greetings to my Marsupilami \\ //
2000/500 Technical Reference Manual: "A1000, the original Amiga" \X/
Ingo Kraupa
>ln -s gugus /usr/local/bin/brabel
(am Amiga hast du sicher einen Alias dafuer... wie ist eigentlich die Reihen-
folge am Amiga? So wie unter Unix (von --> nach) oder umgedreht?)
>mache, muss ich mich auch nicht wundern, dass ich mit /usr/local/bin/brabel
>gugus nur erreichen kann, wenn ich in diesem Directory bin. Das empfinde
>ich nun wirklich nicht als Bug, sondern als Frage, ob der User begriffen
>hat, was ein symlink ist oder nicht.
Genau. Symbolische Links sind doch prinzipiell simpler als Hard Links. Man
kann einen symbolischen Link bedenkenlos loeschen, er wird als ein eigenes
File angelegt (in dem sich nur der Name des eigentlichen Files/Dirs verbirgt),
und das einzige was man eigentlich noch braeuchte waere ein Flag: ich bin
ein symbolic link.
Wobei man damit natuerlich viel Unfug treiben kann. Endlosschleifen sollte
das Filesystem zumindest schon abfangen. Ich habe mich nicht so genau damit
befasst, deswegen entgehen mir vielleicht einige Probleme (amigaspezifische
sowieso).
GruPt Hugi
--
___ _, _______ _______
/ \ __(_)__ |One way\ .^... |End of | A cool Sun 3 is an oxymoron,
STOP! (Q.o) |traffic > |(o,o) | road | unless put in a refrigerator
\___/ ,-<`-')-' |_______/ `<`=')--^ |_______| .... ..- --. .. -... .- --..
| \~/ | \./ | Ingo Kraupa /\ Quittenweg 42
_|_ ./|_ _|_ _|\, _|_ 8510 Fuerth \/ +499119976999