home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!sun-barr!sh.wide!wnoc-tyo-news!sranha!anprda!akira
- From: akira@atson.asahi-np.co.jp (Akira Takiguchi)
- Newsgroups: comp.os.vms
- Subject: Re: flushing in VAXC and DECC
- Message-ID: <3088@anprda.atson.asahi-np.co.jp>
- Date: 29 Dec 92 00:11:31 GMT
- References: <1hjtr9INN34t@gap.caltech.edu> <1992Dec27.200611.24473@nntpd2.cxo.dec.com> <1hn91uINNnna@gap.caltech.edu>
- Organization: ATSON, Inc. (a subsidiary of the Asahi Shimbun)
- Lines: 31
-
- In article <1hn91uINNnna@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU writes:
- >And,
- >byt the way, despite the claim by another person, the program:
- >
- >#include stdio
- >main()
- >{ int fd;
- > fd = creat("TEST.DAT");
- ,0600);
- > write(fd, "This is a test.\n", 16);
- > fsync(fd);
- > sleep(30);
- >}
- >
- >Also exhibits exactly the same behavior.
-
- Thanks for pointing this out. I believe this is (one of) the reason
- why fsync() was undocumented. Since it's documented now in AXP manual,
- doesn't this example work as expected on AXP machines? (I guess Paul used
- AXP machines for testing?)
-
- Anyway, this does not invalidate my argument. Since fsync is named
- after the unix function (though actual semantics is quite different; as
- you know, on unix "written" data are immediatedly shared among processes.
- Fsync() merely guarantees the data is on disk and can be considered safe
- from crash), it should reasonably imitate unix behaviour - no wonder you
- need fflush() before fsync().
- --
- Akira Takiguchi at ATSON, Inc. (a subsidiary of the Asahi Shimbun)
- WAKO GINZA bldg. 8-10-4 Ginza Chuo-ku Tokyo 104 Japan
- +81 3 3289 7051(voice) 7066(fax) EMAIL TO <akira@atson.asahi-np.co.jp>
-