cache.ndk

also zum thema cache.ndk vor dem start löschen...
kannst du machen...sollte kein problem sein...
es dauert nur beim öffnen von dbs vielleicht etwas länger als wenn die cache.ndk da wäre...
ob und wie dadrin ein timer zu werke geht weiss ich auch nicht

Der Cache.ndk macht in der R6 Version folgendes:

ersetzt die Cache.dsk und

Contains all design elements (the design note itself) cached from a server copy of a replica. For multiple replicas, only 1 copy of the design element is cached if they are the same.

Also contains the unread journal which is used to coordinate unread information across multiple replicas when accessed from the same client.

Gruss
SNAKER

Hi,

FINGER WEG vom löschen der Cache.dsk/Cache.ndk einfach nur so.
Die Datei ist da ja aus gutem Grund.
Wenn Ihr das Gefühl habt, dass die Cache.dsk/ndk was macht was sie nicht soll, nicht einfach löschen sondern der Sache auf den Grund gehen.
Ich hab seit 1992 weder desktop.* noch bookmark.* noch cache.* jemals löschen müssen (ausser eines der files konnte überhaupt nicht mehr geöffnet werden).

Stehe gerne für weiterführende Diskussion / Detailinfos zur Verfügung,

HTH,
Florian
http://www.icodex.com/vofsblog

hallo florian,

bei uns wird auf den citrixserver bei jeder anmeldung eine neue cache.ndk erstellt und bis jetzt hab ich da nix nachteiliges bemerkt...
aber ich lass mich gern überzeugen dass das schlecht ist...also sag mal warum man die nicht löschen sollte...

Hiho,

gestatte mir die Frage aus welchem Grund Du die cache.dsk/cache.ndk bei jedem start löschst?

Abgesehen davon:
Die Cache.dsk/ndk soll eben cachen. Das Löschen vor jedem Clientstart/bei jedem Win Logon leert den Cache und der Client fängt wieder von vorne an.
Das mag bei LAN Verbindungen weniger ins Gewicht fallen, bei WAN Verbindungen und ähnlichen kann das bisweilen weh tun - um den Unterschied zu erkennen solltest Du Notes mal eine Zeit lang verwenden ohne den cache zu leeren.

Das Löschen von Files ist bei Notes inzwischen schon Volkssport, ohne das darüber nachgedacht wird ob es wirklich notwendig ist.
Grundsätzlich - unabhängig davon ob es einen sichtbaren(!) unterschied macht - ist das Löschen von Files mE schlichtweg die falsche Methode, da dies max. Symptome behebt aber den Ursachen nicht auf den Grund geht.

Zu guter Letzt sind in der cache.dsk unread mark tables enthalten die sicherstellen daß ungelesene markierungen über mehrere repliken hinweg synchronisiert werden.
Das löschen der cache.dsk/ndk bedingt einerseits dass dieser table immer wieder von grund auf neu erstellt werden muss und kann darüber hinaus dazu führen, daß ungelesene markierungen nicht korrekt über mehrere Repliken hinweg synchronisiert werden.

zwar kann das eine oder andere selten auswirkungen haben, das problem ist aber das "selten".
wenn ungelesene markierungen nicht korrekt synchronisieren beschwert sich entweder keiner, oder keiner nimmt an es wäre das löschen der cache.dsk/ndk schuld oder endbenutzer werden frustriert.

Das Ergebnis ist immer das gleiche - ein Symptom ist behoben, es wurde aber nicht einmal versucht zu ergründen warum es dazu kam.

Ich persönlich kann einfach nicht verstehen, warum einfach so dateien gelöscht werden - ich kenne auch wie gesagt seit 1992 kein einziges support dokument das meint die cache.dsk/ndk sollte gelöscht werden ...

Wiewohl ich der Meinung bin die o.g. Punkte sollten Anlass genug sein den Problemen auf den Grund zu gehen, mag es anderen kleinlich erscheinen - ich glaube es ist bisweilen eine Frage ob man mit Dingen lebt oder Sie unter Kontrolle hat.

vlg flo.

Um der Vollständigkeit halber auch noch Deine Fragen zu beantworten (sorry, ist "im Eifer des Gefechtes" untergegangen :)), anbei noch die Infos zum Timer und dem Inhalt der Cache.dsk/ndk:

Sobald eine Maske, Ansicht etc. gecached worden ist, vergleicht Notes beim Aufruf des Designelements nur noch ob sich dieses am server seitdem verändert hat.

Solange dem gemäss einfachem Timestampvergleich nicht so ist, wird das Element aus dem lokalen Cache verwendet, ansonsten wieder entfernt und "vorne" wieder hinzugefügt.

Für alles andere (Cached Design elements & unread marks) wird ein FIFO (First In First Out) "table" verwendet.
Es gibt also keinen Timer, sondern "alte" Designelemente fallen dann aus dem Cache raus sobald "vorne" wieder soviel dazu gekommen ist, dass nicht genügend Platz ist. (halbwegs verständlich?).

Die Grösse des Caches für Designelement kann eingestellt werden, für Unreadmarks fasst der Table 20.000 Unreadmarks zyklisch ebenfalls nach FIFO Verfahren.

Hoffe das hilft,
vlg Florian
http://www.icodex.com/vofsblog

Barry, was schreibste Dir denn hier zusammen??

Zitat

Ich hab seit 1992 weder desktop.* noch bookmark.* noch cache.* jemals löschen müssen (ausser eines der files konnte überhaupt nicht mehr geöffnet werden).

Ich kann das so nicht ganz glauben. 1992 gab´s noch keine Bookmark.nsf, die desktop.dsk ist doch bei R5 auch umbenannt worden, aber du gebrauchst noch weiterhin die von R3???
Klingt fuer mich nicht ueberzeugend

dnotes, danke dass Du so gut auf mich aufpasst,
"aber"
desktop.* = desktop.dsk, desktop5.dsk, desktop6.ndk etc.
bookmark.* = bookmark.nsf | bookmark.ntf
und cache.* = cache.dsk / cache.ndk

die bookmark.nsf gabs nicht vor R5, richtig, hab ich daher auch damals schon nicht löschen müssen
die desktop.dsk könnt ich wahrlich noch die aus R3 benutzen, weil R4 so nett war und sie konvertiert hat nach dem upgrade und R5 so nett war und R6 so nett war. (hab dazwischen aber zweimal das unternehmen gewechselt und daher die dsk nicht mitgenommen.

aber löschen hab ich da echt noch nie was müssen.

Ich hoffe das wirkt jetzt überzeugender auf dich,
wenn nicht schick ich dir gerne eine R3 dsk und du schaust mal was passiert bei migration via R4, R5 und ND6.
detto cache.dsk/ndk, bookmark.nsf etc.

oh wunder sag ich nur.
und schon hab ich wieder was zusammen geschrieben

vlg flo
http://www.icodex.com/vofsblog