Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.bugs.4bsd
Subject: Re: bug with fsync ?
Message-ID: <3523@umcp-cs.UUCP>
Date: Fri, 22-Feb-85 08:48:00 EST
Article-I.D.: umcp-cs.3523
Posted: Fri Feb 22 08:48:00 1985
Date-Received: Tue, 26-Feb-85 07:56:22 EST
References: <5291@root44.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 30

> Why does dump backup files based on the st_ctime field?

Because it's the only reliable indicator of when an inode was last
touched.  [Aside: I often hear the ctime field called the "creation
time"; it's not.  As far as I can tell the "c" stands for "change".
ctime records the last time the inode was changed in any way.]
Remember that you can set the atime and mtime fields arbitrarily (see
utimes(2)), and also that chmod() can change important things like
access bits without affecting access or modified times.

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

Now that I don't know.  An fsync() on a file which is already synced
"should" do nothing.

> Why does vi 'fsync' files anyway?

To ensure data integrity?  Who knows.  However, fsync() on a read-only
file descriptor *does* make sense: it means make ****ing sure that this
file is all saved away right now.  Fsync doesn't alter files, so write
permission is not implied.

The real bug, then, is that fsync() always updates inode ctimes, even
if nothing happens.  I know that in "4.3", fsync has been rewritten;
was this fixed along the way?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland