bill@twg.bc.ca (Bill Irwin) (11/20/90)
I would like to know ALL the possible activities that could result in a file's access time (ls -lu) being updated. I have performed the following, with the noted result: 1) vi the file and quit without saving (access time updated) 2) TAR archive some files to tape (updated) 3) list file names to a file and printer ls -l > /tmp/list (not updated) ls -l | lp (not updated) Are there any other actions that could be done that would update the access times? Specifically, if you saw many directories of program source code files (over 160 files) that had an access time between 6 and 7pm (after office hours), would you conclude that someone had used an editor and looked at each file within the hour, or would you conclude that the files had been archived to tape or diskette? I just thought of another action that would probably update the access time: using grep to search the files for a pattern. I haven't tested this, but I would assume that grep reads through the files looking for the pattern, which would be the same type of activity as a vi on the file to the OS. This would certainly be a far less sinister activity than archiving source code after hours. I would appreciate any tips in this direction. -- Bill Irwin - The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | UNIX Systems bill@twg.bc.ca (604) 430-4329 (fax) | Integration
shwake@raysnec.UUCP (Ray Shwake) (11/22/90)
bill@twg.bc.ca (Bill Irwin) writes: >1) vi the file and quit without saving (access time updated) >2) TAR archive some files to tape (updated) In both cases, your program opened the file for reading, thus the access time was updated. >3) list file names to a file and printer > ls -l > /tmp/list (not updated) > ls -l | lp (not updated) In these cases, only the inode (containing file information) was accessed, not the files themselves. Thus, access time was not updated. shwake@raysnec
klaus@cnix.uucp (klaus u schallhorn) (11/23/90)
In article <331@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: >I would like to know ALL the possible activities that could result in a file's >access time (ls -lu) being updated. I have performed the following, with the >noted result: > [ ... ] > >Are there any other actions that could be done that would update the access >times? Specifically, if you saw many directories of program source code files >(over 160 files) that had an access time between 6 and 7pm (after office >hours), would you conclude that someone had used an editor and looked at each >file within the hour, or would you conclude that the files had been archived >to tape or diskette? > [ ... ] >Bill Irwin - The Westrheim Group - Vancouver, BC, Canada IMHO access times are changed by accessing a file, be it for reading, writing or replacing contents of your source files with something sinnister. Have a look in TFM under find -atime, what it says for directories accessed by find. klaus -- George Orwell was an Optimist
gwc@root.co.uk (Geoff Clare) (11/27/90)
In <141@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >bill@twg.bc.ca (Bill Irwin) writes: >>1) vi the file and quit without saving (access time updated) >>2) TAR archive some files to tape (updated) > In both cases, your program opened the file for reading, thus > the access time was updated. Minor nit-pick: opening the file is not itself sufficient to update the access time. You do actually have to read some data from the file. E.g. ls < file will not update the access time of "file" because "ls" does not read anything. -- Geoff Clare <gwc@root.co.uk> (Dumb American mailers: ...!uunet!root.co.uk!gwc) UniSoft Limited, Hayne Street, London EC1A 9HH, England. Tel: +44-71-315-6600
jon@jonlab.UUCP (Jon H. LaBadie) (12/04/90)
In article <331@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: >I would like to know ALL the possible activities that could result in a file's >access time (ls -lu) being updated. The way to look at this is that any activity that requires looking at the data in the file (not the inode contents) will update the access time. Copies will, moves on the same file system shouldn't. File type checks probably will. Grep's definitely will. Note also that write's to a file require a read first. You may want to write one character. But disks transfer data in blocks. Thus, to write your one character, the block it will be written in must be read into memory. You will "write" your one character into that memory buffer and the entire block will be written to disk. Thus writes also update access times. Jon -- Jon LaBadie {att, princeton, bcr, attmail!auxnj}!jonlab!jon
tchrist@convex.COM (Tom Christiansen) (12/05/90)
In article <893@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes:
:Note also that write's to a file require a read first. You may want to
:write one character. But disks transfer data in blocks. Thus, to
:write your one character, the block it will be written in must be read
:into memory. You will "write" your one character into that memory
:buffer and the entire block will be written to disk.
:Thus writes also update access times.
Well, that depends. On a Sun, it does; on a Vax (running 4.3) or a Convex
(running basically 4.3 on the insides), it does not. So I wouldn't say
that write ALWAYS udpates access times. It depends on your system.
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
to look at yourself in the mirror the next morning." -me
boyd@necisa.ho.necisa.oz (Boyd Roberts) (12/10/90)
In article <893@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >In article <331@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: >>I would like to know ALL the possible activities that could result in a file's >>access time (ls -lu) being updated. > Reading the data in the file update its access time. >Note also that write's to a file require a read first. You may want to >write one character. But disks transfer data in blocks. Thus, to >write your one character, the block it will be written in must be read >into memory. You will "write" your one character into that memory >buffer and the entire block will be written to disk. > >Thus writes also update access times. > No, that read is not always neccessary. If the write spans the block no read is neccessary. Should a read be necessary, the read happens invisibly in that the access time is not changed. That read is not a true access of the file. It's a side affect of the file-system implementation. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (12/11/90)
Roughly speaking (HP-UX and Domain/OS), the sys/stat.h fields available are: o st_atime Field indicating when file data was last accessed. Changed by the following system calls: creat(2), mknod(2), pipe(2), read(2), readv (on read(2)), and utime(2). o st_mtime Field indicating when data was last modified. Changed by the following system calls: creat(2), truncate(2), ftruncate (on truncate(2)), mknod(2), pipe(2), prealloc(2), utime(2), write(2), and writev (on write(2)). Also changed by close(2) when the reference count reaches zero on a named pipe (FIFO special) file that contains data. o st_ctime Field indicating when file status was last changed. Changed by the following system calls: chmod(2), chown(2), creat(2), fchmod(2), fchown(2), truncate(2), ftruncate (on truncate(2)), link(2), mknod(2), pipe(2), prealloc(2), rename(2), setacl(2), unlink(2), utime(2), write(2), and writev (on write(2)). Consult your favorite man page on "stat" Thomas Gilg tomg@cv.hp.com
cmb@dtg.nsc.com (cb) (12/12/90)
Is there a program that keep a watch on certain set of files. Ideally it should log 1) user name 2) time of access 3) kind of access ( ls, view ..) Thanks
mike@bria.AIX (Mike Stefanik/78125) (12/31/90)
In article <546@dtg.nsc.com>, cmb@dtg.nsc.com (cb) writes: > Is there a program that keep a watch on certain set of files. > Ideally it should log > 1) user name > 2) time of access > 3) kind of access ( ls, view ..) I don't think there is an accounting tool specifically for file access and programs used to access the file. The accton/acctcom accounting tools may give you some of what you want, though. ----------------------------------------------------------------------------- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike "If it was hard to code, it should be harder to use!"