aegl@root44.UUCP (Tony Luck) (02/20/85)
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
chris@umcp-cs.UUCP (Chris Torek) (02/22/85)
> 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