stanonik@nprdc.arpa (Ron Stanonik) (10/05/88)
We're running 4.3bsd on a vax 780. I just noticed that vi'ing a file changes the ctime of the file . . . even if the file isn't modified and even if the file isn't writable. Digging around I found that vi fsync's the file, and fsync seems to be the culprit. fsync results (in the kernel) in a call to syncip, which sets the ICHG bit in the inode's i_flag and then calls iupdat, causing the ctime to be set. Any reason not to remove the line setting the ICHG bit in syncip? Phrased another way, any good reason for fsync setting the ctime? Thanks, Ron Stanonik stanonik@nprdc.arpa
chris@mimsy.UUCP (Chris Torek) (10/05/88)
In article <17247@adm.ARPA> stanonik@nprdc.arpa (Ron Stanonik) writes: >We're running 4.3bsd on a vax 780. ... fsync results (in the >kernel) in a call to syncip, which sets the ICHG bit in the >inode's i_flag and then calls iupdat, causing the ctime >to be set. > >Any reason not to remove the line setting the ICHG bit >in syncip? Phrased another way, any good reason for >fsync setting the ctime? Yes, but the actual behaviour is a bug. Kirk decided it should do this instead: RCS file: RCS/ufs_subr.c,v retrieving revision 1.1 retrieving revision 1.2 diff -c2 -r1.1 -r1.2 *** /tmp/,RCSt1011772 Tue Oct 4 18:26:24 1988 --- /tmp/,RCSt2011772 Tue Oct 4 18:26:28 1988 *************** *** 140,144 **** } } - ip->i_flag |= ICHG; iupdat(ip, &time, &time, 1); } --- 140,143 ---- RCS file: RCS/ufs_syscalls.c,v retrieving revision 1.1 retrieving revision 1.2 diff -c2 -r1.1 -r1.2 *** /tmp/,RCSt1011771 Tue Oct 4 18:26:35 1988 --- /tmp/,RCSt2011771 Tue Oct 4 18:26:36 1988 *************** *** 779,782 **** --- 779,784 ---- ip = (struct inode *)fp->f_data; ILOCK(ip); + if (fp->f_flag&FWRITE) + ip->i_flag |= ICHG; syncip(ip); IUNLOCK(ip); -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris