Fwd: [Monotone-devel] Re: Monotone fails to detect certain changes in files

[Nuno Lucas]

[didn't noticed this ML does't like the reply-to thing]

---------- Forwarded message ----------
From: Nuno Lucas <address@hidden>
Date: Aug 26, 2007 4:31 AM
Subject: Re: [Monotone-devel] Re: Monotone fails to detect certain
changes in files
To: Pavel Cahyna <address@hidden>


On 8/25/07, Pavel Cahyna <address@hidden> wrote:
> On Fri, Aug 24, 2007 at 05:03:15AM +0100, Nuno Lucas wrote:
> > I believe the problem is that I used a small data conversion program
> > that changed the files by mmaping them (it's a small utility to
> > convert files with a MS-DOS codepage to ISO-8859-1 and some few other
> > simple character table-based conversions), and it seems that use-case,
> > with the "noatime" mount option, doesn't get noticed.
> >
> > Not sure if it really is a bug or something I should expect because of
> > the way my system is setup and the way I work with the mmaped file.
>
> Does your small utility use msync()? Apparently without msync, file
> modification change is supposed to be updated "at some point in the
> future", which might be after monotone checks it.

No, it doesn't. It releases the resources properly (instead of simply
exit), but doesn't do any msync. I replayed my test.c sample with an
explicit msync(addr,len,MS_SYNC) at the end, but got the same behavior
as before.

Looking more throughly at the [f]stat manpage(s) (including the POSIX
manpages), noticed the case without msync is unspecified. It is
specified what happens with atime if the "noatime" is not used, but
nothing is said about what happens if "noatime" is used:

-----------------------------------------
       Not all of the Linux filesystems implement all of the time
fields.  Some file system types allow mounting in such a way  that
file
       accesses do not cause an update of the st_atime field. (See
'noatime' in mount(8).)
-----------------------------------------

Ok, this is expected behavior.

-----------------------------------------
       The  field  st_atime  is  changed  by  file accesses, e.g. by
execve(2), mknod(2), pipe(2), utime(2) and read(2) (of more than zero
       bytes). Other routines, like mmap(2), may or may not update st_atime.
       The field st_mtime is changed by file modifications, e.g. by
mknod(2), truncate(2),  utime(2)  and  write(2)  (of  more  than  zero
       bytes).   Moreover,  st_mtime of a directory is changed by the
creation or deletion of files in that directory.  The st_mtime field
       is not changed for changes in owner, group, hard link count, or mode.
       The field st_ctime is changed by writing or by setting inode
information (i.e., owner, group, link count, mode, etc.).
-----------------------------------------

Notice how they say atime can be ignored on mmap uses, but don't
specify what hapens when mmap is used with mtime and ctime.

The equivalent POSIX manpages do the same, so it almost seems it was
made on purpose just for this case.

Interestingly enough, my tests with msync showed that Linux is
"broken" (relative to POSIX) in this case because, even if "noatime"
is set, it should have set mtime if there was a write. But it may be a
filesystem/driver thing, not a general Linux issue (only tested on a
reiserfs v3 partition).

In a nutshell, it almost seems like the absence of a specification for
this case explains it, although at the same time it doesn't when one
uses msync (shows a POSIX violation) .


Best regards,
~Nuno Lucas

>
> Pavel