On 3/26/07, Vincent Lefevre <firstname.lastname@example.org> wrote:
> On 2007-03-24 14:52:32 -0400, Mark Phippard wrote:
> > I would also add that if we did add ctime checking, then OK, on some
> > OS's in some fairly rare situation we would work better, But, since
> > ctime can be updated to the current time by many fairly common
> > operations,
> Which ones? The main one is chmod, but the average user shouldn't need
> it much often in practice. The other ones shouldn't be needed either
> by the average user.
I saw references on this list that implied backups can cause it, but maybe
it was just restores?
> we will actually be making the product much slower, and
> > therefore worse, for likely a larger percentage of users.
> No, this is wrong if the method is chosen via an option, e.g. most
> users could choose the mtime-only solution, while Linux users (in
> particular those who use recode and mv in some ways and don't do
> operations that change the ctime) could choose the max(mtime,ctime)
> solution. So, everyone would be happy.
Adding an option seems like overkill. If someone is burned by this problem
the are just going to be pissed to find out there was an obscure option
available. If someone knows about the problem and the commands that cause
it, they can also use touch or work around the problem in other ways. There
still have not been any great examples of why this is a huge problem,
especially when the trunk code with the additional file size check is added.
A solution that does a full file compare could still be useful. For
> instance, such a svn status could be run every night and mail warning
> messages to the user if something suspicious occurred (including
> a hardware-related problem that corrupted a file without changing
> the inode data).
You always have the option of running touch, and then you will get your full
compare. I do not see adding options as a solution, but I do not see us
ever agreeing on this either.
Received on Tue Mar 27 03:35:43 2007