Bug #1308
closedhammer: stat returns wrong time when using tids
0%
Description
When stat'ing a file with tid, hammer seems to always return the "first" time
for mtime, not the real mtime.  However undo -i can retrieve this time, so it
possibly isn't lost.
How to reproduce:
touch foo2 && fsync foo2 && sleep 5 && echo foo >> foo2 && fsync foo2 && sleep 5
&& echo foo2 >> foo2 && fsync foo2
then undo -i and stat any given foo2@@0x..., you'll always see the initial time,
except if you use tid -1.
       Updated by dillon over 16 years ago
      Updated by dillon over 16 years ago
      
    
    :When stat'ing a file with tid, hammer seems to always return the "first" ti=
:me
:for mtime, not the real mtime.  However undo -i can retrieve this time, so =
:it
:possibly isn't lost.
Note that the fixed mtime/atime for files accessed via a TID is to
    ensure that snapshots remain consistent.  Otherwise if you do something
    such as tar up a snapshot and pipe it to md5, and then do it again
    later, you will get a different result.We may be able to do some refinement there, but whatever is returned
    by the snapshot has to be returned every time the snapshot is accessed.-Matt
       Updated by corecode over 16 years ago
      Updated by corecode over 16 years ago
      
    
    Ah now I see, it always reports to ctime of the inode.  I suppose we don't 
keep track of mtimes then?
cheers
   simon
       Updated by dillon over 16 years ago
      Updated by dillon over 16 years ago
      
    
    :Ah now I see, it always reports to ctime of the inode.  I suppose we don'=
:t=20
:keep track of mtimes then?
:
:cheers
:   simon
mtime and atime are updated in-place, without rolling a new inode
    record, so a snapshot will not snapshot either field unless some
    other action (e.g. like a file append, chmod, chown, etc) rolls a
    new inode record after the snapshot was made.Because of this the snapshot stat code always reports the ctime in
    the atime and mtime fields to guarantee consistency.It is possible to change this behavior, but probably not desirable 
    since it could very well result in a large number of inode records
    getting rolled for no good reason (particularly for atime updates).-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>