bin/91622: /bin/cp does not update atime of the source file

Bruce Evans bde at zeta.org.au
Tue Jan 10 22:40:10 PST 2006


The following reply was made to PR bin/91622; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: joe <freebsd-security at FreeBSD.org>
Cc: freebsd-gnats-submit at FreeBSD.org, freebsd-bugs at FreeBSD.org,
        dds at FreeBSD.org
Subject: Re: bin/91622: /bin/cp does not update atime of the source file
Date: Wed, 11 Jan 2006 17:34:58 +1100 (EST)

 On Wed, 11 Jan 2006, joe wrote:
 
 >> Environment:
 > RELENG_4 20051028
 >> Description:
 > [cp fails to update atime]
 >
 > this occurs regardless of whether or not the user has
 > rwx permissions on the source file. does not apply of
 > course if the source filesystem is mounted read-only.
 > they are read-write here.
 >
 > since the source file is indeed being read, the atime should be updated.
 
 This is because cp(1) doesn't actually read(2) the file.  It mmap(2)'s the
 file and reads memory.
 
 POSIX doesn't seem to require that cp sets atimes or otherwise acts as
 if it reads the file.
 
 Similar for cmp(1) and other utilities that use mmap() to read files
 (install(1) is another).
 
 The problem is mostly fixed in -current by "setting" (not actually
 setting, but marking for update) atimes in mmap().  I think to be
 strictly correct, setting of atimes should be nearer to munmap(2) than
 mmap().  No read has occurred from userland's viewpoint at mmap() time.
 However, since the OS can't tell if applications read mmapped memory
 unless their is a pagefault, the atime would have to be set on every
 pagefault to be as correct as possible, and I think mmap() prefaults
 some pages so it would have to set the atime whether or not the
 application reads the pages.  So I think setting atimes in mmap() is
 required in practice.  This leaves the problem that later pagefaults
 never set the atime, so the atime set by mmap() becomes out of date.
 I think the atime should be set by mmap() of there is at least one
 later pagefault.  Setting it for every pagefault may be too inefficient.
 
 Bruce


More information about the freebsd-bugs mailing list