Using rsync for backup trashes st_atime

[jw schultz]

On Thu, Oct 24, 2002 at 01:19:40PM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2002-10-24 04:04:14 -0700, jw schultz <jw at pegasys.ws>
> wrote in message <20021024040414.A6256 at pegasys.ws>:
> > On Thu, Oct 24, 2002 at 12:16:26PM +0200, Jan-Benedict Glaw wrote:
> > > I think '--preserve-server-atime' would be a nice additional feature,
> > > and I tend to implement it on monday or so. I haven't yet looked at the
> > > source, so there may be already a solution to this problem. If you think
> > > this is a nice feature, please give some response...
> > 
> > .from rsync3.txt by Martin Pool
> > |  - Propagate atimes and do not modify them.  This is very
> > |    ugly on Unix.  It might be better to try to add
> > |    O_NOATIME to kernels, and call that.
> 
> It's not yet there, and SUSv3 doesn't propose it either...

I sited this to show that it is considered an issue; not for
the O_NOATIME.

> > It would be better to call it --reset-access-time as cpio
> > does.  Not only to make it easier to remember (for those
> 
> I don't care about the feature's name. So I'll use --reset-access-time
> or --atime-preserve (as tar does).

Sure, i don't care much.  Just that if you can reuse a name
for the same option of another tool it is a bit more
consistent.  I'm a bit more inclined to call it reset
instead of preserve, but only a bit.

> > using other tools) but to make it clear that the access time
> > is being reset to a value that will not reflect accesses by
> > other activity between initial stat and the final reset.
> > 
> > Beyond that I don't much care.  All my filesystems are mounted -o
> > noatime,nodiratime for efficiency.
> 
> However, you're loosing data by this:-) You can't tell when some last
> access has happened...

In more than 15 years of UNIX i've only had one instance
where atime was usefull.  It simply isn't valuable enough
info save for very special cases.  Flushing those inodes to
disk (esp on journaled filesystems) is more overhead than it
is worth.

> > Personally, i think any MUA that depends on atime is broken by design.
> 
> You're using one of them. Despite that, MUAs come to my mind which might
> want to use st_atime. But there might exist other applications as well.
> This is why I care about the issue. My st_atimes will be correct some
> minutes later (as I receive huge amounts of email), though.

Despite what the manpage says i've not had any problem with
mutt recognising the presence of new mail or bad
interactions with assorted biffs or backups.   This is
apparently because of the noatime mount.  I did some tests
and the noatime option only affects implicit activity touch
-a does change the timestamp and mutt gets confused but
simply reading the file has no adverse affect.
Interesting.

At least until you get the option added you might chattr +A
your mail folders.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt