Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site root44.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!mcvax!ukc!kcl-cs!root44!aegl
From: aegl@root44.UUCP (Tony Luck)
Newsgroups: net.bugs.4bsd
Subject: bug with fsync ?
Message-ID: <5291@root44.UUCP>
Date: Wed, 20-Feb-85 13:59:28 EST
Article-I.D.: root44.5291
Posted: Wed Feb 20 13:59:28 1985
Date-Received: Tue, 26-Feb-85 06:19:01 EST
Organization: Root Computers Ltd., London
Lines: 21
Xpath: kcl-cs west44

A couple of days ago while perusing a backup tape (made with /etc/dump)
I was surprised to find several files that I was sure shouldn't have been
changed recently. Checking with 'ls' showed that they hadn't been modified
-but the inode modified time had been updated very recently. I remembered
having 'vi'ed the file - but not as superuser i.e. without any write access.
Further investigation showed that 'vi' would reset the st_ctime field of
any file - regardless of write permission or desire (even when invoked as
view). The cause is an 'fsync' call. Many questions remain:

	1) Why does dump backup files based on the st_ctime field?

	2) Why does the the st_ctime field on a file get updated when
	   you use 'fsync' on a file descriptor open only for reading?

	3) Why does vi 'fsync' files anyway?
Any theories on any of the above topics would be greatly appreciated
before I wade in and hack the offending programs to shreds.


	unisoft!root44!rootcl!aegl
	mcvax!ukc!root44!aegl