On 11.03.2013, at 23:54, Andrew Wong wrote:
> On 3/11/13, Max Horn <[email protected]> wrote:
>> Looking at the git config man page to check what each of my config settings
>> does, I discovered "trustctime". And adding
>> trustctime = false
>> to .git/config made the rebase work, every single time. Huh.
>>
>>
>> Adding this to the fact that a clone works fine, I wonder if something *is*
>> touching my files, but just in that directory. But what could it be? One
>> nagging suspicion is the "file versioning" feature Apple introduced as part
>> of Time Machine in OS X 10.7; it's kind of a "version control system for
>> n00bs" for arbitrary documents. It has caused me some pain in the past.
>>
>> But I just re-checked, and problematic repos is explicitly on the Time
>> Machine exclusion list. I also used the "tmutil isexcluded FILES" to verify
>> that the problematic files are really on the TM exclusion list. Finally, I
>> moved the one of the repos subdirectory containing most of the problematic
>> files, and then run "git checkout". In other instances, this sufficed to
>> "disassociate" a file from an unwanted TM version history. But doing that
>> had no effect here, i.e. also with the freshly regenerated files, the
>> problems appear.
>
> Would you be able to turn off Time Machine completely and do a few
> tests? If it does works, then it becomes a matter of fixing Time
> Machine...
I did turn it off just now, but no effect. Then again, daemons like revisiond
were still running...
One more thing: I used the "fs_usage" to monitor what process accessed what
file during one of those failing "git rebase" runs. I then searched through
this to determine which processes accessed the "bad" file in this time. The
result where these processes (aggregated):
git
revisiond
fseventsd
git-merge-recursive
Note that Time Machine was not running, but revisiond is... from its manpage:
revisiond is the daemon that manages document revisions created by
applications and system services.
There are no configurations to revisiond, and users should not run
revisiond manually.
This is the process I am suspecting. Specifically, a fchflags call it makes
(see that attached excerpt of the fs_usage output). I am not sure, but my guess
would be that it sets SF_ARCHIVED on the file. Causing its ctime to wander...
Yuck.
But I don't know how to control it... and I am not sure if I can just kill it.
Hrm. I'll try to dig some more into it, perhaps I can somehow confirm that this
is *really* the cause of the problems, and somehow prevent it.
Cheers,
Max
00:59:54.349156 lstat64 src/BAD_FILE
0.000050 git.623953
00:59:54.349160 open F=5 (R_____) src/BAD_FILE
0.000004 git.623953
00:59:54.350659 close F=5
0.000007 git.623953
00:59:54.371716 lstat64 src/BAD_FILE
0.000002 git.623955
00:59:54.429674 lstat64 src/BAD_FILE
0.000002 git.623959
00:59:54.600060 lstat64 src/BAD_FILE
0.000007 git.623959
00:59:54.600151 stat64
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000006
revisiond.623963
00:59:54.600154 stat64
/Users/mhorn/the-path-to-my-repository/src 0.000003
revisiond.623963
00:59:54.600160 open F=7 (R_____)
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000006
revisiond.623963
00:59:54.600161 fstatfs64 F=7
0.000002 revisiond.623963
00:59:54.600163 close F=7
0.000002 revisiond.623963
00:59:54.600387 unlink src/BAD_FILE
0.000328 W git.623959
00:59:54.600429 open F=5 (_WC__E) src/BAD_FILE
0.000039 git.623959
00:59:54.602910 write F=5 B=0x4000
0.000040 git.623959
00:59:54.602932 write F=5 B=0x4000
0.000017 git.623959
00:59:54.602947 write F=5 B=0x4000
0.000011 git.623959
00:59:54.602958 write F=5 B=0x4000
0.000009 git.623959
00:59:54.602969 write F=5 B=0x4000
0.000009 git.623959
00:59:54.602977 write F=5 B=0x12f5
0.000007 git.623959
00:59:54.602983 fstat64 F=5
0.000004 git.623959
00:59:54.603032 close F=5
0.000049 git.623959
00:59:54.621731 lstat64
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004
fseventsd.1664
00:59:54.882870 lstat64 src/BAD_FILE
0.000002 git.623993
00:59:54.882872 open F=5 (R_____) src/BAD_FILE
0.000003 git.623993
00:59:54.883042 close F=5
0.000002 git.623993
00:59:55.021956 lstat64 src/BAD_FILE
0.000003 git.624027
00:59:55.021959 open F=4 (R_____) src/BAD_FILE
0.000003 git.624027
00:59:55.022138 close F=4
0.000003 git.624027
00:59:56.600440 open F=7 (R_____)
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000014
revisiond.623963
00:59:56.600442 fcntl F=7 <GETPATH>
0.000002 revisiond.623963
00:59:56.600445 close F=7
0.000004 revisiond.623963
00:59:56.600449 stat64
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004
revisiond.623963
00:59:56.600452 stat64
/Users/mhorn/the-path-to-my-repository/src 0.000003
revisiond.623963
00:59:56.600455 open F=7 (R_____)
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004
revisiond.623963
00:59:56.600457 fstatfs64 F=7
0.000002 revisiond.623963
00:59:56.600459 close F=7
0.000002 revisiond.623963
00:59:56.600687 open F=7 (R_____)
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000006
revisiond.623963
00:59:56.600688 fstat64 F=7
0.000002 revisiond.623963
00:59:56.600698 fchflags F=7 <UNKNOWN> [garbled output
removed] 0.000010 revisiond.623963
00:59:56.600701 close F=7
0.000003 revisiond.623963
00:59:56.624161 lstat64
/Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.000004
fseventsd.1664
00:59:56.981172 lstat64 src/BAD_FILE
0.000004 git.624517
00:59:57.015622 lstat64 src/BAD_FILE
0.000005 git.624527
00:59:57.118844 lstat64 src/BAD_FILE
0.000005 git-merge-recurs.624544
01:00:00.194634 lstat64 src/BAD_FILE
0.000002 git.624580
01:00:00.194637 open F=5 (R_____) src/BAD_FILE
0.000003 git.624580
01:00:00.194815 close F=5
0.000003 git.624580
