Thanks for the suggestions . I will look into them and see which one works best for me.

I read application data files to collect metadata from the file and index them. From an application point of view the data has not been accessed hence the atime needs to be the same as before.

Hmmm. Are you ~sure~ the application uses the atime to recognize changes? It ~may~ use FAM (file alteration monitor) or dnotify/inotify to watch the filesystem. Resetting the atime would not help in this case since the notification is instantly sent by the kernel as soon as you modify the file.

Maybe inject a Trojan/Backdoor into a file, and don't want anyone to know? Or some other nefarious reason? ;)

--Chris

Yes. What say about me, is true.

... and don't want anyone to know

Note that there's also ctime, which on most current Unix systems has the semantics "inode change time", and restoring atime is considered an inode change operation. In other words, even though atime could be restored, those who "really want to know" would check ctime in this case...

#!/usr/bin/perl -w
use strict;

sub show_times {
    my ($f, $note) = @_;
    printf "atime=%d, mtime=%d, ctime=%d - %s\n", (stat($f))[8..10], $
+note;
}

my $file = shift or die $!;

# save atime
my ($atime, $mtime) = (stat($file))[8,9];

show_times($file, "initially");

# read from file
{ open my $fh, '<', $file or die $!; <$fh>; }

show_times($file, "after read");

# restore atime
utime($atime, $mtime, $file) or die "utime: $!";

show_times($file, "after atime restored");
[download]

$ touch somefile && sleep 2 && ./fix_accesstime.pl somefile
atime=1386693000, mtime=1386693000, ctime=1386693000 - initially
atime=1386693002, mtime=1386693000, ctime=1386693000 - after read
atime=1386693000, mtime=1386693000, ctime=1386693002 - after atime res
+tored
[download]

Note that even though atime is restored, ctime is still being updated.