It is strongly suggested that you do this in a temporary subdirectory. After using the old version, it is a good idea to delete all files in that subdirectory; then you will never run this risk of getting the wrong version of Walnut.load.
The steps necessary to convert from the old Walnut, to Walnut 6.0 are:
(1) Edit your user.profile
(a) If you have Walnut.AutoNewMail set to
TRUE, change it to
FALSE (the default)
You do not want to have mail automatically retrieved once you have started this conversion. You could end up with mail in the old Walnut, once the dump had finished.
You'll have to destroy the Walnut window and start it again, if you change the option while Walnut is running.
(b) add the new entry:
Walnut.WalnutRootFile: "[Server.alpine]<user.registery>Walnut.Root"
where server is Ebbetts (unless you have been told to use Luther).
This root file will be stored on the alpine-server. it contains the names of all the other files that the new Walnut will use.
(c) Do not put Walnut in your PerLogIn or NewUser commands.
(c) save your profile (and on a file server if you want)
(2) Start up the old Walnut; type
WalnutDump to the CommandTool.
Wait until the dump has finished.
WalnutDump writes a local file that contains only the messages that have not been deleted.
(3) Rollback (if you have run the old Walnut) - that's why you have this hardcopy.
(a) If Walnut is in your checkpoint, you'll have to do a full boot. Make a new checkpoint that does not include Walnut. Remember, (the new) Walnut is still changing.
(b) REMEMBER: Do not put Walnut in your PerLogIn or NewUser commands.
(3a) Open this file again, using the name above - you'll want to select from it.
(4) Get the new Walnut, type (to the CommandTool)
(a) cd ///Commands/ -- or whatever directory you want to use
(b) Bringover -p /Cedar/CedarChest6.0/Top/Walnut.df
At this point, you could still go back to the old Walnut without doing anything special (except for doing a bringover of the old Walnut (from [Indigo]<Walnut>Top>Walnut.df) to get the old Walnut.load). After initializing the new Walnut files, it is still possible to get back, but you'd have to do a scavenge. Once you start actually running the new Walnut, it is still possible to revert, but you'd have to deal with the new mail that the new Walnut has retrieved.
The new Walnut automatically retrieves mail from grapevine into a file on alpine and then waits for the user to bug NewMail; the mail then gets copied onto the log file and added to the database.
(5) type
CreateWalnutWorld to the CommandTool, preferably in the same subdirectory
as the bringover used.
Read the comments (reproduced below).
(a) "some rope" is a key that gets stored in the log files and database, to help tie them together. In the commands below, "some rope" MUST appear in double quotes. The rope should be different for each user, perhaps something like
"User's mail database"
(b) The alpine-server MUST be that same as used in the Walnut.WalnutRootFile entry.
-- Two commands, CheckAndInit & InitWalnutFiles
-- have been registered
-- Each will manufacture an appropriate root file from
-- a template, store it on a specified alpine server, and initialize
-- the other walnut files
-- each has the format:
-- command "some rope" alpine-server
-- "some rope" is an arbitrary rope (in double quotes)
-- (it is stored in the database and log files)
-- alpine-server is a name, such as Luther or Ebbetts
--
CheckAndInit "Some rope" alpine-server
-- first checks that
-- ///Walnut/user.registry/Walnut.templog is readable
-- then creates the root and other files on the server
-- do this if you did a WalnutDump from the old Walnut
--
InitWalnutFiles "Some rope" alpine-server
-- this just creates the root and other files on the server
An example would be:
CheckAndInit "Willie-Sue's mail database" Ebbetts
(5) Type the
CheckAndInit
or
InitWalnutFiles command, with appropriate arguments.
Remember, you need to run only one of CheckAndInit or InitWalnutFiles, not both.
If you did a CheckAndInit and there was a disk error reading the tempLog, DO NOT continue. Ask Willie-Sue what to do if you've not dealt with bad pages before.
(6) Once you have been told that the Walnut files are properly initialized, type
Walnut
to the CommandTool.
(7) If you did a WalnutDump, type (to the CommandTool)
WalnutOldMailReader ///Walnut/user.registry/Walnut.TempLog
This reads your dumped messages and stores them in the new log and database. This can take some time for a large log file; you will be informed of progress.
(8) Now you can set Walnut.AutoNewMail (in your profile) to
TRUE if you like.
This would cause Walnut to automatically copy the newMailLog onto the log and add the messages to the database; the flag goes down when this has been done.
(9) Look at WalnutDefault.profile for new options and old ones that have disappeared.
(10) MsgSetButtons and message TOC entries within msgSet displayers are now TiogaButtons.
They look and act similar to the ones in the old Walnut, but you can do Find's, and shift-leftButton to stuff the TOC entry into the primary selection, and other Tioga things to them (except primary or secondary selection).
(11) Open a WalnutSend window (e.g., by bugging Sender in the Walnut control window),
do a Get of /Cedar/CedarChest6.0/WalnutKernel/NewWalnut6BackupRequest.form. Fill in your name in the Cc field (or delete that field), and the Reply-To field. Fill in the Alpine-Server with the server used for your root file. Send the message.
(12) Known bugs:
(a) DON'T delete all the messages from a displayed msgSet - the world locks up.
(b) Autoscrolling of message sets doesn't work.