[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 2746] New - update overwrites w/o warning local modification if local timestamp did not change

From: Vincent Lefevre <vincent+svn_at_vinc17.org>
Date: 2007-03-24 01:20:09 CET

On 2007-03-21 18:48:50 +0100, Erik Huelsmann wrote:
> On 3/21/07, Vincent Lefevre <vincent+svn@vinc17.org> wrote:
> >On 2007-03-21 15:50:07 +0100, Erik Huelsmann wrote:
> >> ctime is not reliable in the face of networking filesystems.
> >
> >This is the first time I've heard about that. I know that atime is
> >not reliable (for efficiency reasons), but what are the problems
> >with ctime?
> It's not indicative of anything that happened as a result of user
> action: it may change due to processes run by an administrator too.
> That means that where mtime and file size changes are normally caused
> by things the user did, ctime changes don't necessarily -probably
> generally even- indicate that. [*]

OK, I can see that on one of my accounts, e.g.

Access: 2006-11-29 17:33:34.000000000 +0100
Modify: 1995-12-21 18:09:28.000000000 +0100
Change: 2007-03-11 21:51:53.000000000 +0100

It doesn't seem to occur much often though. Instead of using mtime +
file size (which is not reliable enough as far as I'm concerned), why
not try to solve the ctime problem?

For instance, if the user whishes, it is possible to update the status
every night in background with a cron job, so that the user will
almost never see any problem.

Now the problem with ctime is not critical, i.e. the user won't lose
data if ctime is used. So, why not make an option so that the user
could choose between mtime and ctime[*], depending on the tools he
uses and his system?

[*] or max(mtime,ctime).

> [*] As indicated in
> http://groups.google.nl/group/gnu.misc.discuss/browse_thread/thread/6e8fa32ef66f5fa6/24c55a64b4e6c7b5?lnk=st&q=filesystem+ctime+problem&rnum=31&hl=nl#24c55a64b4e6c7b5
> backup software or other processes which restore atimes can and will
> cause ctime changes.

It also says that the mtime can be back-dated, thus cannot be trusted,
and no-one says that tools which back-date the mtime are broken and

Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 24 01:20:25 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.