From: gm@germal.bs.open.de (Gerald Malitz)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: Nonbinding und multiple Assigns (WAS: Re: Probleme mit parnet)
Date: Mon, 31 Aug 1992 14:54:55 GMT
 <5AVwr*kT1@germal.bs.open.de> <1992Aug21.112924.12528@rz.uni-karlsruhe.de>
X-Newsreader: Arn V1.00 beta rel2

In article <1992Aug21.112924.12528@rz.uni-karlsruhe.de>, Angela Schmidt writes:

> In article <5AVwr*kT1@germal.bs.open.de>, gm@germal.bs.open.de (Gerald Malitz) writes:
> Ja, aber wozu haben wir denn Nonbinding Assigns? (Sorry, in meinem
> letzten Posting ueber parnet hatte ich genau diese gemeint, aber 
> Assign DEFER geschrieben *schaem*)

	Irgendwie habe ich Dich schon verstanden :-)

>   Fuer Non-Parnet-Leute                   Fuer Parnet-Leute
>   Assign PDF1: DF1: PATH   - oder auch -  Assign PDF1: NET:DH0/C PATH
>   Assign DDF1: DF1: DEFER  - oder auch -  Assign DDP1: NET:DH0/C DEFER
>
> Wuenschenswert waere, dass ein
>   Assign C: PDF1: ADD
>     oder ein
>   Path PDF1: ADD
> den unaufgeloesten Assign in die entsprechende Liste mitaufnimmt, so
> dass also immer die aktuelle Volume aus PDF1: in der Assign- bzw.
> Path-Liste ist. Leider wird einfach nur der aufgeloeste Lock in die
> jeweilige Liste eingehaengt.

	Hmm, Locks haben aber auch ein paar Vorteile, die ich durchaus
schaetze.  Sie verhindern z. B., dass ein File oder Directory geloescht
wird, das noch in Gebrauch ist.  Unter Unix passiert es mir gelegentlich,
dass ich einen Verzeichnisbaum loesche, in dem eine andere Shell noch
ihr CurrenDirectory hat :-)  Und ich kann Objekte umbenennen (und damit
auch in ein anderes Directory verschieben), ohne dass es fuer den alten
Benutzer verloren geht.

	Wenn ich fuer parnet vermehrt `symbolische Assigns' (im
Gegensatz zu den alten `Hard-Assigns' ;-) ) benutzen muss, bedeutet
das ein geaendertes Verhalten des des Dos.  Das aber widerspricht
der (meiner :) ) Wunschvorstellung, dass parnet moeglichst transparent
sein sollte.  Um die zu erreichen, muesste parnet selber Soft-Assigns
verwalten.  Zu jedem Lock, das der parnet-Client ausgibt, muss er
neben der Referenz auf ein Lock auf dem Server auch die Information
behalten, wie er zu diesem Lock gekommen ist.  Praktisch wird das wohl
heissen, dass der Client den Filenamen mit abspeichern muss.  Damit
kann er die Server-Locks wiedergewinnen, sobald der Server wieder da
ist.

	Das ist natuerlich mit zusaetzlichem Aufwand verbunden und
auch nicht problemfrei.  Wenn ich ein Objekt, auf dem ein Lock lag
umbenannt habe, wird der Client es nach einem Reboot des Servers
nicht wiederfinden.  Eine geregelte Moeglichkeit, den Server herunter-
zufahren, koennte die Situation verbessern.  Erst dann wuerde der
Client die Filenamen speichern, die er aktuell mit FileNameFromLock
erstellt.

	Hucha, irgendwie fuehrt das inzischen doch recht weit.. :-)
So richtig schoen wird das ganze sowieso erst mit einer einheitlichen
Schnittstelle zwischen FileSystem und Device, so dass ich ein
FileSystem wahlweise auf parnet, sernet, EtherNet, ISDN etc. setzen
kann =:^}

> Bei DDF1: faende ich das ja auch richtig - schliesslich _soll_ der
> Assign da ja beim ersten Ansprechen aufgeloest werden, aber bei
> PDF1: waere es doch sehr wuenschenswert, wenn der Assign jedesmal
> neu aufgeloest wuerde.

	Das dauert dann natuerlich auch entsprechend laenger.

>     Angela

	Tschuess, Gerald.

-- 
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: +49 531 796832
\X/ gm@germal.bs.open.de                      Mittagspause von 0.30 - 23.45 Uhr