home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.sun.admin
- Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!malgudi.oar.net!chemabs!lwv26
- From: lwv26@cas.org (Larry W. Virden)
- Subject: Re: Moving calendar info
- Message-ID: <1992Sep7.113859.20274@cas.org>
- Followup-To: comp.sys.sun.admin
- Sender: usenet@cas.org
- Reply-To: lvirden@cas.org (Larry W. Virden)
- Organization: Nedriv Software and Shoe Shiners, Uninc.
- References: <Bu0sun.9t3.2@cs.cmu.edu> <1992Sep4.112549.6934@tin.monsanto.com>
- Date: Mon, 7 Sep 1992 11:34:57 GMT
- Lines: 21
-
- In article <1992Sep4.112549.6934@tin.monsanto.com> nghoff@albert.monsanto.com (Norman G. Hoffman) writes:
- :Kerien Fitzpatrick (fitz@frc.ri.cmu.edu) wrote:
- :: You must first kill the running rpc.cmsd process *before* copying the callog
- :: file. I believe it is because rpc.cmsd keeps everything in memory and then
- :: writes it out.
- :
- :Are you sure about this? It's hard to believe my latest calendar entries
- :aren't safe from a system crash. If it is true, is there a "flush"
- :operation I can perform after updating my calendar?
-
- There is no flush operation. The latest changes made by the calendar manager
- itself ARE safe - but the changes made by an outside force are not. The
- daemon is under the opinion that all changes made are made by it - thus
- it need only read the spool file one time - at start up. In fact, if I am
- not mistaken, it writes out its in memory version on a regular basis, so
- your changes get clobbered after a while.
- --
- Larry W. Virden UUCP: osu-cis!chemabs!lvirden
- Same Mbox: BITNET: lvirden@cas INET: lvirden@cas.org
- Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
- America Online: lvirden@aol.com
-