[Unionfs] Re: timestamp/mtime related bugs, probable fix

[pascal at pabr.org]

Erez Zadok wrote:
> 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).

OK, so "lower" is non-null only once in the loop, and all is fine.


> If one uses utimes(2) to change the inode time absolutely, we just take
> those times as is in ->setattr.

My concern is about someone using utimes() on a lower inode.
I believe the following script demonstrates the problem:

#/bin/sh
D=/tmp
mkdir $D/b0 $D/union
mount -t unionfs -o dirs=$D/b0 none $D/union
date > $D/b0/old
sleep 1
touch $D/b0/data
ls -als --full-time $D/b0/data $D/union/data
cp -a $D/b0/old $D/b0/data
ls -als --full-time $D/b0/data $D/union/data
umount $D/union
rm -r $D/b0 $D/union

Result:

0 -rw-r--r-- 1 root root 0 2007-12-18 15:02:48.666545207 +0100 /tmp/b0/data
0 -rw-r--r-- 1 root root 0 2007-12-18 15:02:48.666545207 +0100 /tmp/union/data
4 -rw-r--r-- 1 root root 29 2007-12-18 15:02:47.661546000 +0100 /tmp/b0/data
4 -rw-r--r-- 1 root root 29 2007-12-18 15:02:48.666545207 +0100 /tmp/union/data

The timestamp in the fourth line is incorrect because
unionfs_copy_attr_times() does not refresh timestamps
which have decreased since the previous copy.

Pascal