VCacheToDo(7)

Name

VCacheToDo - things to do to complete the VCache(1)

Contents

To Do - Major Items

These are the major items that still need to be done. In some cases, a small amount of design work is required.

To Do - Required

These are items that must be taken care of before the cache server is completed.

To Do - Enhancements

These are items that are not necessary for the correct functioning of the cache server, but they will improve its effeciency or enhance its functionality.

Done

The following items have been completed.

Done on Tue Sep 5 2000 by KCS
Several race conditions in writing to the stable cache have been fixed. First, it was possible for a second call to one of the cache server's log-flushing methods (CacheS::FlushUsedCIs, CacheS::FlushGraphLog, CacheS::FlushCacheLog) to return if there was nothing to flush, even if another thread was still in the process of flushing the corresponding log. This could allow information to be written to disk out of order, resulting in inconsistent stable state. This was corrected by forcing the flushing methods to always make use of the FlushQueue mechanism. Secondly, there was a race condition in the code for VToSCache which allowed new entries to be added to the MultiPKFile being flushed between the time the graphLog (and hence, the usedCILog) were flushed and the time the VPKFiles within the MultiPKFile were checkpointed. This made it possible for a new entry created during that window to appear in the stable cache without appearing in the graphLog, thereby violating one of the cache invariants (B7x, according to the todo item previously listed above). The VPKFiles are now checkpointed before the graph log is flushed, thereby guaranteeing that all entries written to a MultiPKFile will have their CI allocations and graph log entries recorded.

Done on Mon Jul 6 09:17:54 PDT 1998 by heydon
The code that arranges to call the routine for cleaning the cache log is overly simple. This item was addressed quite a while ago, but I only recently noticed it was no longer a problem.

Done on Tue Apr 15 09:23:10 PDT 1997 by heydon
Shipped v1.11.

Done on Mon Apr 14 09:21:59 PDT 1997 by heydon
Fixed bug in leases implementation in which the backround expiration thread was deadlocking. The problem was that the Leases::Debug method had too low a locking level.

Done on Mon Mar 24 16:28:07 PST 1997 by heydon
Shipped v1.10.

Done on Mon Mar 24 16:27:44 PST 1997 by heydon
Added code to prune the usedCILog and graphLog.

Done on Tue Mar 18 14:00:20 PST 1997 by heydon
Shipped v1.9.

Done on Tue Mar 18 13:47:48 PST 1997 by heydon
Added a timestamp to Root entries in the graphLog. Currently, this field is unused, but in the future it may be used by the weeder to automatically keep roots that are new enough, even if the weeder wasn't explicitly told to keep them.

Done on Tue Mar 18 13:46:48 PST 1997 by heydon
Changed recovery code so that it no longer reverts from cache state 1 back to state 0. This work is now done in the WeederRecovering method, but only if the weeder did not finish its marking work.

Done on Tue Mar 18 10:37:25 PST 1997 by heydon
Fixed bug in recovery of emptyPKLog in which all records but the first in the emptyPKLog for a given PK were being ignored.

Done on Mon Mar 17 10:39:16 PST 1997 by heydon
Made many changes to the cache server's weeder interface.

Done on Thu Mar 13 10:39:16 PST 1997 by heydon
Shipped v1.8.

Done on Thu Feb 27 10:39:16 PST 1997 by heydon
Changed the signature of the Checkpoint method to include the fingerprint of the directory containing the evaluated model.

Done on Thu Dec 19 16:49:37 PST 1996 by heydon
Shipped v1.7.

Done on Thu Dec 19 15:53:22 PST 1996 by heydon
Added -n switch to CreateCacheDirs(1).

Done on Thu Dec 19 15:35:05 PST 1996 by heydon
Changed BitVector's to use slightly more compact representation in memory and on disk.

Done on Thu Dec 19 09:32:08 PST 1996 by heydon
Added new "isEmpty" result to the "FreeVariables" method. This required that the cache server protocol version be incremented.

Done on Wed Dec 18 15:23:19 PST 1996 by heydon
Changed VCache::HandleFailure to print the error message in all cases (even if the debugging level is "None") if it represents a non-standard SRPC failure.

Done on Wed Dec 18 15:21:40 PST 1996 by heydon
Fixed memory smash bug in VestaVal::T::Print. A value of type signed char was being cast to a value of type unsigned int; sign extension was causing the sprintf of the resulting value to overflow the buffer. I added assertions to all similar sprintf statements to assure that they weren't overflowing their buffers.

Done on Thu Dec 12 16:45:10 PST 1996 by heydon
Shipped VCache v1.6.

Done on Thu Dec 12 15:31:08 PST 1996 by heydon
Occassionally, the MultiPKFiles were being created with bizarre names. The bug turned out to be in the use of the "form" function in the SMultiPKFile::Name method. This function does not seem to be thread-safe. All uses of the "form" function have now been eliminated.

Done on Wed Dec 11 13:36:46 PST 1996 by heydon
Fixed a bug in PrintCacheLog in which EmptyPKLog was not being opened read-only. This meant that vestasrv priviledges were required to run the program. Opening the file read-only fixes that problem.

Done on Wed Dec 4 11:53:14 PST 1996 by heydon
Shipped new CleanCache(1) script. Also, made EraseCache(1) and ShowCache(1) scripts more robust.

Done on Wed Dec 4 08:42:56 PST 1996 by heydon
Shipped VCache v1.5. This version writes a magic number into the header of a MultiPKFile.

Done on Mon Dec 2 13:38:04 PST 1996 by heydon
Shipped new VCacheStats(1) program.

Done on Mon Nov 25 13:40:14 PST 1996 by heydon
Shipped VCache v1.4. Mainly, this was to pick up new libraries. In addition, this version no longer supports the GetLookupStats method, since that information (and lots more) can now be collected using etp and pspec.

Done on Mon Oct 28 11:42:10 PST 1996 by heydon
Shipped VCache v1.3.

Done on Mon Oct 28 11:40:59 PST 1996 by heydon
Added support to SMultiPKFileRep::Header::Write for writing entries of type SMultiPKFileRep::HT_SortedList.

Done on Sat Oct 26 15:37:28 PDT 1996 by heydon
Shipped VCache v1.2.

Done on Sat Oct 26 15:03:57 PDT 1996 by heydon
Added support for writing SPKFile header entry format SPKFileRep::HT_SortedList; also added support to SPKFile::LookupCFP for looking up common fingerprints efficiently for that header entry format.

Done on Wed Oct 23 09:22:22 PDT 1996 by heydon
Shipped VCache v1.1.

Done on Tue Oct 22 23:43:05 PDT 1996 by heydon
Changed cache server and SRPC implementation so no forked thread ever dies; instead, they loop endlessly waiting on a condition variable for work to do. This was done in the hope of avoiding the garbage collector crash.

Done on Wed Oct 9 17:56:42 PDT 1996 by heydon
There is a race condition in AddEntry: the test that leases on the "kids" and on the deriveds have not expired must be moved to after the code that writes the graphLog entry. As it is now, the code differs from the spec: the test now occurs even before the new CI is created and leased. But the spec is wrong too: the test must occur after the graphLog entry is written. Otherwise, the following could happen. First, the test for necessary leases might pass. Then, between that time and the time the graph log entry is written, one of the necessary child or derived leases might expire. If the weeder ran, the corresponding entry or derived would be deleted, since the graph log entry that would protect it has yet to be written. We would then create a cache entry that contained a non-existent child or derived! Hence, we must write a speculative graphLog entry, and then check that the necessary leases exist before creating and installing the entry. If that test fails, we may have a "ghost" entry in the graph log, but it will not have a parent to protect it, and eventually its lease will expire. It will then be deleted from the graph log by the weeded, at which point the cache server can re-use its cache index.

Done on Tue Oct 1 14:36:04 PDT 1996 by heydon
Fixed a bug in QuickWeed(1): it was not handling the case in which the repository call to create a file was failing.

Done on Tue Sep 24 15:30:35 PDT 1996 by heydon
Shipped VCache v1.0. This was the first version of the cache server that printed an explicit version number.

Done on Tue Sep 24 15:08:41 PDT 1996 by heydon
Changed QuickWeed(1) to weed against multiple caches.

Done on Mon Sep 23 17:20:26 PDT 1996 by heydon
Changed QuickWeed(1) to detect if an error occurs writing the derived keep file, and to abort in the event of such an error.

Done on Mon Sep 23 16:56:04 PDT 1996 by heydon
Fixed EraseCache(1) script so it now asks for confirmation before deleting anything.

Done on Mon Sep 16 11:28:15 PDT 1996 by heydon
Once copies were made of cache entries at MultiPKFile flush time, the previous change was not necessary. Now that the cache entries in VPKFiles are immutable, so there is no reason the entries in the cache log cannot contain pointers to those entries.

Done on Fri Sep 13 17:36:57 PDT 1996 by heydon
There is a bug with the storage of cache entries in the volatile cache log. The problem is that the cache log stores a pointer to the newly-added cache entry. Because of this alias, there is a race condition: the cache entry is not protected by the appropriate VPKFile lock when the cache log is flushed to disk. This could produce a crash as follows: if two threads simultaneously flush the cache log and a MultiPKFile to stable storage, the thread flushing the MultiPKFile might modify a new cache entry in the course of updating its common names. The modified entry might then be flushed to the cache log before the new version of the MultiPKFile was committed. If the server then crashed, it would see the modified entry on recovery. To avoid a race, the cache log must store copies of any mutable cache entry fields.

Done on Fri Sep 13 17:36:32 PDT 1996 by heydon
There is a race in SMultiPKFile::Rewrite: some fields of a VPKFileChkPt point back to the original VPKFile, so they should only be accessed with the VPKFile lock held. In particular, combined fingerprints may be unlazied in the process of flushing the entries to disk, so a lock must be held for those operations. The fix is for the checkpoint to include copies of the mutable fields of any cache entries in the initial VPKFile.

Done on Fri Sep 13 14:54:36 PDT 1996 by heydon
When a log is checkpointed, any old logs and checkpoints associated with it should be deleted. Tim will be adding this functionality to VestaLog, so the cache server will pick it up for free.

Done on Fri Sep 13 14:37:38 PDT 1996 by heydon
Changed PrintCacheLog and PrintGraphLog programs to open the logs in read-only mode. As a result, these programs no longer have to be run as vestasrv.

Done on Mon Sep 9 16:58:18 PDT 1996 by heydon
Change CacheS::FlushAll so it forks threads to flush up to five MultiPKFiles to the stable cache at once.

Done on Mon Sep 9 15:09:13 PDT 1996 by heydon
When a short string (such as a ShortId) is fingerprinted, only the high-order bits of the fingerprint words are significant. Unfortunately, the PKPrefix interface was selecting these insignificant bits from the PK to use to form the name of the corresponding MultiPKFile. As a result, many otherwise-unrelated PK's were ending up in the same MultiPKFile. I've changed the PKPrefix interface to use the high-order bits instead.

Done on Sat Sep 7 19:54:49 PDT 1996 by heydon
The EraseCache(1) program should not allow the possibility of deleting the logs without deleting all of the stable MultiPKFiles. This will lead to problems. For example, if the usedCIs log is deleted, the first new entry will be assigned a cache index (CI) of 0. But there may already be a cache entry with index 0 in the stable cache! So I've removed the -entries option from EraseCache(1); now that program always deletes the stable cache files.

Done on Fri Sep 6 19:17:22 PDT 1996 by heydon
There was a bug in SMultiPKFileRep::AppendNewHeaderEntry. This bug was actually causing a memory smash whenever a MultiPKFile was flushed to disk!

Done on Wed Sep 4 19:27:31 PDT 1996 by heydon
An assertion in the code for reading a SPKFile was failing due to a PKFile growing larger than 64K. Each SPKFileRep::HeaderEntry contains an offset to the start of each list of entries (grouped by common fingerprint). The offset was being stored as a 2-byte unsigned short, which was not large enough to hold values over 64K.

Done on Wed Sep 4 19:27:02 PDT 1996 by heydon
Yuan reported a bug in which flush a MultiPKFile to disk was failing. The failure was evinced by an FS::Failure exception indicating a seek failure to location 0 of the original (non-existent) MultiPKFile. The bug is caused by the case in which the table of VPKFiles to flush contains some VPKFiles with no new entries, yet those VPKFiles do not exist in the MultiPKFile on disk. The fix is to simply not include those VPKFiles in the MultiPKFile header, so they will not be written to disk.

Done on Mon Jul 22 14:24:40 PDT 1996 by heydon
Implemented policy for caching "warm" cache entries in a VPKFile's oldEntries table. New code was necessary to get the entries from the in-memory SPKFile rather than updating the old entries in memory (as was originally done). The problem with the original strategy is that "warm" entries produced from disk hits were incomplete, and so did not have sufficient information (such as a complete list of fingerprints) to be updated when the PKFile's set of common names changed at PKFile flush-time.

Done on Fri Jul 19 08:29:49 PDT 1996 by heydon
Removed all timestamps and the max-timestamp heuristic from the cache server code. For the rationale behind this change, see my post to src.vesta on 15-July-96.

Done on Mon Jul 15 10:32:47 PDT 1996 by heydon
Added GetLookupStats method for reporting statistics about the cache server's Lookup method.

Done on Mon Jul 8 11:53:18 PDT 1996 by heydon
Changed printing routines so PrintMPKFile(1) would use a multi-line format for the "allNames" and "imap" fields.

Done on Mon Jul 1 13:42:21 PDT 1996 by heydon
Changed PrintMPKFile(1) to take relative pathnames as well as absolute ones. Relative pathnames are interpreted relative to the directories specified in the Vesta configuration file.

Done on Thu Jun 27 15:10:04 PDT 1996 by heydon
Fixed recovery bugs that were not updating the length of stable cache log or the number of entries in a VMultiPKFile correctly.

Done on Mon Jun 24 13:51:42 PDT 1996 by heydon
Fixed bug in CacheS.C that was causing the cache server to crash if it did not detect the right files in its metadata directory structure. The bug was due to an unhandled exception, and was fixed by moving a call inside an existing "try" scope.

Done on Thu May 23 12:41:41 PDT 1996 by heydon
Added -noHits command-line option.

Done on Thu May 9 16:26:46 PDT 1996 by heydon
Implemented the "CleanCacheLog" routine and arranged for it to be called automatically whenever the size of the cache log exceeds some threshold.

Done on Thu May 9 16:25:46 PDT 1996 by heydon
For now, the only calls to CacheS::VToSCache are in CacheS::Checkpoint and in the DoDeletions thread. The Checkpoint method flushes all pending VMultiPKFiles, one at a time. The server should be changed to invoke VToSCache based on some resource-usage policy. Currently, the solution is to flush a volitile MultiPKFile when the number of entries in it exceeds some threshold.

Done on Fri Apr 12 18:51:00 PDT 1996 by heydon
Added code to print names and timestamps one per line.

Done on Fri Apr 12 18:39:38 PDT 1996 by heydon
The code for recovering the cache log was going to disk to reach the "pkEpoch" on every entry in the log. I added a temporary table mapping PK's to their pkEpoch's to improve the efficiency of recovering the cache log.

Done on Fri Apr 12 18:38:16 PDT 1996 by heydon
The locking level requirements were not being respected during recovery. I changed the recovery code to acquire the appropriate locks in a correct order.

Done on Tue Apr 9 17:08:52 PDT 1996 by heydon
The table constructed at recovery from the EmptyPKLog needs to be preserved in memory and used to initialize the "pkEpoch" of newly- created VPKFiles. Also, it needs to be augmented when an SPKFile is deleted and have an entry removed when a non-empty SPKFile is written.

Done on Mon Apr 8 15:09:01 PDT 1996 by heydon
I removed the locks associated with VMultiPKFiles. Now, the fields of a VMultiPKFile are protected by the centralized lock "CacheS.mu".

Done on Sun Apr 7 15:02:51 PDT 1996 by heydon
The cache server specification contained a mistake in which deleted entries were not being ignored when the cache log was recovered. I designed and implemented a pkEpoch algorithm for ignoring deleted and flushed entries in the cache log.

Done on Fri Apr 5 15:03:48 PDT 1996 by heydon
Added "fvs" return value to the cache server "Lookup" method as requested by Yuan.

Done on Wed Apr 3 15:03:11 PDT 1996 by heydon
Changed cache server client interface so that free variables are represented by Text sequences instead of as simple Texts as requested by Yuan. The new free variable types are defined in the "FV2" interface.

Done on Mon Mar 18 16:02:32 PST 1996 by heydon
When a MultiPKFile is empty, we currently delete the file. However, if there are no longer any files in its directory, we should remove the directory (and recursively).

Done on Mon Mar 18 11:52:21 PST 1996 by heydon
When the "WeededMPKs" log is checkpointed, the old log and (empty) checkpoint file are no longer needed and can be deleted. The "version" file written by the VestaLog implementation can be used to determine which log and checkpoint files are safe to delete.

Done on Tue Mar 5 14:06:10 PST 1996 by heydon
If the list of free variables passed to the AddEntry method contains any duplicates, the current code will not detect it. Instead, it should return a CacheIntf::BadAddEntryArgs result.

Done on Tue Mar 5 12:24:02 PST 1996 by heydon
There is no support for the sUsedCIs log shrinking when cache entries are deleted.

Done on Tue Mar 5 12:23:11 PST 1996 by heydon
The body of the cache server's DoDeletions thread must still be implemented.

Done on Tue Mar 5 12:22:57 PST 1996 by heydon
Once we support deleting an SPKFile from a MultiPKFile, it is possible for a MultiPKFile to become empty. In that case, we should delete the MultiPKFile itself.

Done on Tue Mar 5 12:21:39 PST 1996 by heydon
SMultiPKFile::Rewrite does not yet support deleting of entries. When it does, we have to handle the case of an empty SPKFile. In that case, no SPKFile should be written to the MultiPKFile.

Done on Tue Mar 5 12:21:25 PST 1996 by heydon
SPKFile::Update does not yet support deleting of entries. Once it does, we have to consider the case that all the entries from a PKFile are deleted, in which case the SPKFile should not be included in the MultiPKFile, and the corresponding VPKFile should be removed from the cache.

Done on Tue Mar 5 12:21:04 PST 1996 by heydon
Once the weeder is implemented, the set of common names may actually grow at VtoSCache time. Currently, the methods for recomputing the fingerprints of existing cache entries at this time are written under the assumption that the common names will only get smaller (and hence, that the uncommon names will only be augmented). Is there a way to generalize this code (using XOR instead of OR?) to handle the new case once the weeder is implemented?

Done on Mon Jan 22 18:24:08 PST 1996 by heydon
The cache server's weeder interface still needs to be designed and implemented. New code will also be necessary to handle the deletion of deriveds and cache entries (see more specific items below).

Done on Mon Jan 22 18:21:33 PST 1996 by heydon
CacheS::Recover should not recover entries from the cache log that are in the hitFilter if deleting is true.

Done on Mon Jan 22 17:48:29 PST 1996 by heydon
The hitFilter and deleting variables in CacheS must be written stably and recovered in the Recover method.

Done on Sun Jan 21 20:41:27 PST 1996 by heydon
Currently, AddEntry chooses new ci by finding an unset bit in the usedCIs bit vector. However, according to the spec, it is not allowed to choose a cache index in the hitFilter set if deleting is true.

Done on Fri Jan 19 11:38:43 PST 1996 by heydon
The Leases class needs a method call for returning the set of all leased cache entries.

Done on Fri Jan 19 09:35:08 PST 1996 by heydon
There is no facility for disabling lease expiration.

Done on Thu Dec 14 17:28:51 PST 1995 by heydon
We still need a way for the cache to detect if a derived lease has expired. This mechanism has been designed (see Allan's post to src.vesta on 14-Dec-95), but it has not been implemented. As described in that message, the interface to the cache server will have to change to include an extra timestamp argument to the AddEntry method. The cache server also has to export a new RenewLease method for renewing the lease on a specified cache entry.

Done on Tue Dec 5 16:56:56 PST 1995 by heydon
Currently, the names in a VPKFile are stored twice: once in the allNames list and once in the nameMap table. It seems a bit of a waste to store the strings themselves twice. Perhaps the type of allNames should be changed to a list of pointers to texts to save space?

Solution: The actual solution was to provide an alternate implementation of the Text interface in the vesta/basics package that copies pointers rather than buffers when texts are copied.

Done on Fri Nov 10 18:01:50 PST 1995 by heydon
VPKFile::Update currently does not update the contents of the entries table when the set of common names changes.

Done on Fri Nov 10 17:51:57 PST 1995 by heydon
VPKFile::VPKFile(fp) should read the SPKFile from the stable cache in the event that there is no VPKFile in the (volatile) cache instead of always creating a new one from scratch.

Done on Wed Nov 8 10:21:35 PST 1995 by heydon
The SMultiPKFile::OpenAtomicWrite method does not create any necessary directories. Once it computes the pathname fpath, is should create any non-existent directory for all directories along the path (except for the last arc, which names the file itself).

Done on Tue Nov 7 11:24:11 PST 1995 by heydon
Add a void Copy(T &tbl) throw () method to Table::T. This makes the table object a (shallow) copy of tbl. It could be used in VPKFile::CheckPoint and VMultiPKFile::ToSCache, among other places. Another possibility is to also add a constructor that takes a (const T *tbl) argument; this would simply call Copy(*tbl).

Done on Tue Nov 7 09:47:00 PST 1995 by heydon
Provide a "copy constructor" for a BitVector that takes a BitVector* (so it isn't a true copy constructor)? This could be used in SPKFile::Update (twice).

Done on Sat Nov 4 17:20:16 PST 1995 by heydon
Change first arg of SMultiPKFile::OpenRead from FP::Tag to PKPrefix?

Done on Tue Oct 10 14:05:06 PDT 1995 by heydon
Currently, the method CacheEntry::NewEntry sets the commonNames to the set of all free variables when the very first entry is added under a PK. This violates invariant B2v of the spec, but it makes for better testing until we actually have stable PKFiles. There is a comment in this method that describes how to change the code to make it correct.

Done on Fri Sep 22 12:49:33 PDT 1995 by heydon
Change newUncommon and newCommon fields of a VPKFile from tables to lists. They used to be tables indexed by CI, but that aspect of their representation is never exploited. Instead, they are only iterated over, so it makes more sense to represent them as linked lists.

Done on Fri Sep 1 16:39:51 PDT 1995 by heydon
Add timestamps as arguments to the Lookup() and AddEntry() calls.

Done on Thu Aug 31 14:00:40 PDT 1995 by heydon
Change LimService interface so the handle_failure callback takes an extra (void*) arg. Then, change the cache server so SRPC failures at client-disconnect time are only printed when the debugging level is sufficiently large.

Done on Thu Aug 31 11:09:25 PDT 1995 by heydon (actually earlier)
Currently, the implementation of CacheC ignores SRPC failures. Should they be exposed to the client? Should we attempt to catch SRPC failures due to programming errors and crash the program in such cases (as is currently done in LimService)?

Solution: We simply relay SRPC::failure exceptions to the client. (Actually, we catch them in some cases, but then rethrow them.)

Done on Thu Aug 31 11:25:20 PDT 1995 by heydon (actually earlier)
When Roy releases new SRPC interface, use the constructor for the failure class in LimService where a new failure is consed together and thrown.

Done on Thu Aug 31 11:39:49 PDT 1995 by heydon (actually earlier)
Currently, LimService attempts to distinguish SRPC::failure exceptions due to programming errors from those due to system failures. Roy believes this is not robust; the two classes of errors cannot be distinguished by failure code alone.

For now, LimService writes an error message and dies if it detects a failure due to what it thinks is a programming error. Roy says he may want to simply catch programming errors in SRPC, in which case only the failure with code LSErrorCode should be caught in LimService as a fatal programming error (this code is used if the SRPC connection is no longer alive after the callback procedure has returned -- it can only occur if the programmer of the callback routine catches SRPC::failure contrary to the requirements of the callback routine spec).

Solution: In LimService, we only catch the failure with internal code LSErrorCode. All other failures are reported by invoking the user-supplied FailureCallBack.

Done on Mon May 1 17:54:19 PDT 1995 by heydon
Change BitVector interface to provide iterators. These can be used in the NamesXOR and NamesFP functions in CacheEntry.C as well as perhaps the Lookup and AddEntry methods in PKFile.

Done on Mon May 1 17:54:24 PDT 1995 by heydon
It might be a performance win to store the uncommon names in the CacheEntries rather than (or in addition to) the set of all names for that entry. Storing only the uncommon names might be possible, since it can only grow to include new elements. This means that the UpdateTags method would need to take an extra bit vector of the names that were once common that no longer are.

Done on Mon May 1 17:54:24 PDT 1995 by heydon
The PKFile::AddEntry method allocates a new TextKey for each of the free variables. This seems like a waste, since the TextKey values that are not inserted into the nameMap are deleted immediately. However, the creation of each TextKey requires that space for the string be allocated, and the string characters copied. That seems a waste; it would be better to allocate new TextKey's only for those names that are new and must be inserted into the nameMap.

Done on Tue Jan 31 14:22:10 PST 1995 by heydon
In Marshall.cxx, fix the routines for marshalling and unmarshalling lists of fingerprints to use generic sequences, rather than sequences of strings. The current implementation breaks if any of the fingerprints contains a '\0' character, since it will be treated as a terminator.

See Also

VCache(1), VCacheImpl(7), VCacheLocks(7), VCacheSources(7)

Authors

Allan Heydon (caheydon@yahoo.com)

Kenneth C. Schalk (ken@xorian.net) 

Last modified on Mon Mar 11 22:15:40 EST 2002 by ken@xorian.net
     modified on Mon Jul  6 09:44:46 PDT 1998 by heydon
This page was generated automatically by mtex software.