Git annex status always showing annexed files as modified

git-annex/ forum/ Git annex status always showing annexed files as modified

Edit
RecentChanges
History
Preferences
Branchable
7 comments

install
assistant
walkthrough
tips
bugs
todo
forum
comments
contact
thanks

Hi,

Whenever I sync files with windows, it shows the every binary file as modified. I've just cloned "fresh" repo from a linux host and git annex geted the 15-11-03 folder. Running git annex status 15-11-03 shows

M ..\15-11-03/ADL Update 11-03-15.pptx
M ..\15-11-03/Gaming-Rage-Face.jpg
M ..\15-11-03/eluted-absorption-spectra.png
M ..\15-11-03/elution.png
M ..\15-11-03/prep-diagram.png
M ..\15-11-03/rc-elution-01 (2015 Nov 03).csv
M ..\15-11-03/rc-elution-02 (2015 Nov 03).csv
M ..\15-11-03/rc-elution-03 (2015 Nov 03).csv
M ..\15-11-03/rc-prep-01.h5
M ..\15-11-03/rc-test-1 (2015 Nov 03).csv
M ..\15-11-03/rc-test-2 (2015 Nov 03).csv
M ..\15-11-03/wash-absorption.png

Edit: I should add that this repo is untrusted. Doing sync on it just ends up pulling from remotes, not pushing anywhere:

λ git annex sync
commit  (recording state in git...)
ok
pull origin
ok
pull github
ok

How would I check if this is a problem with my installation or a bug in git annex?

RSS Atom

comment 1

In particular, I have set up Gpg4Win to use a smart card for ssh-ing. It provides its own sha executables that are on the path and I wonder if that is the reason that the files always show up as modified.

Comment by aloukian — Fri Nov 6 17:33:32 2015

Remove comment

comment 2

git annex status doesn't checksum files, so it can't be the sha executables in PATH.

Instead, git-annex status, when in a direct mode repository like on windows, checks the recorded timestamps etc of the files to determine if they're modified.

I suppose one possibility is a time zone change or DST change. Did you recently "fall back" from DST in your location?

Due to the braindead way Windows deals with timezone changes, the timestamps of files appear to change when the timezone has changed. git-annex tries to detect this situation and offset to get back a stable timestamp that can be used to detect file modifications, but I can't say that I've tested this situation very carefully, beyond the one very painful day implementing that workaround.

Anyway, running git annex sync may result in it noticing that nothing has actually changed and get the status display to work better.

Comment by joey — Tue Nov 10 19:31:18 2015

Remove comment

comment 3

Well, sync'ing didn't help, though I didn't do sync --content. I'll try that and maybe it will work.

Comment by aloukian — Tue Nov 10 20:35:58 2015

Remove comment

comment 4

I've been having the same problem on windows direct repository and now that I think about it, it could have started after daylight savings time (I also had the windows ssh upgrade problems that took a few days to figure out around the same time). No matter what I do I can't get it to stop showing up as modified in the status view. I've tried sync, sync --content, adding them again, etc. My status output is getting huge as everything I've added on windows is showing up there as modified now. I'm not sure if it's affecting the performance of status or sync (status is just generally very slow on windows direct repos with increasing number of files).

Comment by neocryptek — Sat Nov 21 17:52:26 2015

Remove comment

comment 5

Aloukian were you able to get anything to help? Nothing I've tried has helped.

Joey any more ideas (besides ditching windows )?

Comment by neocryptek — Fri Dec 18 18:09:54 2015

Remove comment

comment 6

Sorry I haven't had a chance to think about this problem any more. The v6 repository format I've been working on should eliminate class problem anyway. It will let git itself be able to tell if annexed files are modified or not.

But there is something you can try to debug what's going on.

Run the git bash shell and cd to your repository's directory.
cat .git/annex/sentinal.cache and paste its content.
stat .git/annex/sentinal --terse and paste the output of that.
Pick one of the files wrongly showing as modified. Run stat $file --terse and paste the output of that.
And then this command should output the inode cache for the file. Be sure to replace $file with the name of the file: cat $(git annex find $file --format='.git/annex/objects/${hashdirlower}${key}/${key}.cache)

But hmm, as I was running windows to get these instructions, I seem to have reproduced the problem myself! In my case:

The sentinal.cache contained data matching the stat of the sentinal file.
The annexed file's mtime and size (and even inode) matched the cached values.
git annex status showed the file as modifed; git annex sync found nothing to commit and didn't change that.

Some more debugging and.. It seems this is not a horrible windows-specific time zone problem. Thank goodness. Instead, what's going on is that git -c core.bare=false status does not show these files as typechanged, but as modified instead. Since git annex status only has special case handling for typechanged files, it just passes the M through and displays it.

So, this is only a display problem, and thus nothing to worry about really. Ie, the rest of git-annex's behavior should not be impacted at all.

It's not windows specific.. Same happens on FAT on Linux. I think git's behavior probably changed since an earlier version; I'm pretty sure its status showed typechanged before. Anyway, I've fixed the status display, on these systems it will now treat files git says are modified the same as typechanged, and so will use git-annex's inode cache info to diplay an accurate status for them.

Comment by joey — Sat Dec 19 16:30:55 2015

Remove comment

comment 7

version 6.20160114 fixes the problem on windows and status seems to be faster now (probably due to all the overhead of printing text to the console).