[comp.unix.admin] What action updates a file's ACCESS time?

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!"