I found an additional clue to the write-behind mtime issue. Some more
copies again showed that zero-length files were getting proper mtime.
Non-empty files again had an mtime associated with the copy EXCEPT for
these two files:
-rw-r--r-- 1 root root 131072 2006-07-11 08:48 /backup/usr0/share/samba/lowcase.dat
-rw-r--r-- 1 root root 131072 2006-07-11 08:48 /backup/usr0/share/samba/upcase.dat
Well, my write-behind has "option aggregate-size 131072"! I'm guessing
that's not a coincidence...
Thanks,
Brent
On Fri, 13 Apr 2007, Brent A Nelson wrote:
On Wed, 11 Apr 2007, Krishna Srinivas wrote:
Also regarding write-behind+mtime bug, can you check out the
latest code and see if rsync or "cp -a" still sees the problem?
Avati made has some changes.
write-behind still has an mtime bug. I "cp -a"'ed a /usr directory and all
non-empty files had file creation time/date for their mtime rather than the
original mtime. Directories have the correct mtime, and zero-length files
have the correct mtime on both underlying filesystems, however, so this is
working. But whenever it writes actual data, it seems like it must be doing
this after the mtime is set, changing the mtime, or the mtime is never
getting set.
Thanks,
Brent
