Re: [tlug] Ubuntu 13.10 clock problems (was: Ibus and Ubuntu based)

["Stephen J. Turnbull" <turnbull@example.com>]

Lyle H Saxon writes:

 > Well, based on the word "modified", I would prefer a file not be
 > considered modified unless there has been some change.

Prepare to spend a lot of time waiting for your computer, then.  In
order to check accurately for modifications, the whole file needs to
be read.  If you don't have a good hash available (aka checksum or
message digest), you need to actually compare the content.  If you
have a program that tracks a bunch of large files (a photograph,
audio, or video manager, for example), this is very expensive.

In practice, what is done is some heuristics are used.  The POSIX
heuristic that there are several timestamps associated with a file
(creation, access, modification, status change) is usually quite
useful (ie, comparing modification timestamps of source and generated
files is a very useful heuristic used by make).

I'm not sure why this heuristic led to confusion in your case.  

Note that git, which has the responsibility for keeping some of the
world's most valuable software safe, uses this heuristic, too.  What
it does is that when you invoke "git status", it just checks time
stamps.  If it sees that the current time stamp is later than it
thinks it should be, it reports that the file was modified.  (In the
usual case for me, I invoked an editor, modified the file, changed it
back for some reason, and then saved it.)  But when you try to commit
the allegedly "modified" file, it compares content, discovers they're
the same, and refuses to record the change.  (It *is* possible to
force the commit, but you have to specify the --force option.)  The
reason for this behavior, of course, is efficiency.

This happens to me reasonably frequently, but it's arguable that the
file actually *was* modified, it just had no net effect. :-)