[Unionfs] Re: timestamp/mtime related bugs, probable fix
Erez Zadok
ezk at cs.sunysb.edu
Tue Dec 18 08:36:20 EST 2007
In message <fk87i9$4j3$1 at ger.gmane.org>, pascal at pabr.org writes:
> This patch looks promising, thanks, I will be testing it too.
>
> Erez Zadok wrote:
> > + (upper inode time being the max of all lower ones).
>
> By the way, I find this policy a little odd.
>
> For regular files, it looks like if one lower branch has the
> highest mtime and another branch has the highest ctime,
> then the timestamps of the upper file will not match those
> of any individual lower file (which would be disturbing).
> Is that correct ?
We don't mix ctime/atime/mtime: it's the max of each individual type. So
atime, ctime,and mtime change individually.
For regular files it's a little different b/c the invariant for
non-directories is that only one lower object is looked up at the time (so
the "max" becomes a straight copy).
> Besides, in order to preserve the invariant, the implementation
> seems to assume that lower timestamps can only increase over
> time (which is not true).
If one uses utimes(2) to change the inode time absolutely, we just take
those times as is in ->setattr.
> Wouldn't it be safer to reset the
> timestamps at the beginning of unionfs_copy_attr_times() too ?
Hmmm, possible, I'll take a look. Thanks.
> Pascal
Erez.
More information about the unionfs
mailing list