Please describe the problem.
When checking an adjusted (unlocked) branch, after a while (a few hours), without modifying anything but running several times "git status", a lot of files are reported as "modified" by "git status".
What steps will reproduce the problem?
On a ~1.5To repo with 1Go to 4Go files, running "git adjust --unlock" works, but after a while "git status" reports a lot of files being modified, "git restore myfiles" restores the files, but other files are reported by "git status" as modified...
What version of git-annex are you using? On what operating system?
git-annex version: 8.20201103, Debian sid
Please provide any additional information below.
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[annex]
uuid = 56c81321-3ca1-4464-8c42-b4b405a2502d
version = 8
thin = true
autocommit = false
[receive]
denyCurrentBranch = updateInstead
[filter "annex"]
smudge = git-annex smudge %f
clean = git-annex smudge --clean %f
$ git status
Refresh index: 100% (4703/4703), done.
On branch adjusted/master(unlocked)
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: file1.avi
modified: file2.avi
...
It took 3.88 seconds to enumerate untracked files. 'status -uno'
may speed it up, but you have to be careful not to forget to add
new files yourself (see 'git help status').
no changes added to commit (use "git add" and/or "git commit -a")
# End of transcript or log.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
It's almost perfect :-).
.gitattributes
in the meantime? I think git annex's smudge/clean filter will then return the hash of the new backend and that differs from the one of the old backend, so git reports the files as changed.You mean between the "git annex adjust" and the "git status"? No, I did nothing at all :(.
After running "git restore" some files (but not all, it seems to be the first N files ordered alphabetically) are still marked as modified, some others get modified again after another "git restore"... Weird!
I've never seen this behavior, but it seems that if git thinks the files are modified, either
git diff
orgit diff --cached
must show some kind of change, and seeing what that change might be would be a useful clue to what happened.I'd say around 50% of the files are reported as modified by "git status".
git --no-pager diff --cached --output git-annex-cached-diff.diff
returns instantly, with no output and nothing ingit-annex-cached-diff.diff
.git --no-pager diff --output git-annex-diff.diff
ran for around 5 hours, with no output and nothing ingit-annex-diff.diff
.Being on sshfs makes me wonder if perhaps something synthesized by that filesystem is confusing git, so eg it thinks the inode or mtime of a file has changed and so it's modified.
However, normally git status does the same work to verify if there's really a modification as git diff does (running the smudge filter in this case). So I'm not clear what's going on here, but it's currently looking more like a problem at the git level, or a filesystem that is too wonky for git to work well, rather than anything git-annex can do.
I have to wonder why you'd even use git-annex on sshfs. The more usual way would be to have a local repository with a remote using ssh to access the server.
I have a local repo (without most of the files) with Debian sid and a remote using ssh, on a server with Debian stable. The files are big, so it is easier to access them with sshfs, to avoid copying them. I wanted to use adjusted branches for users who access the files with gnome/nautilus (via sshfs integration) which is not clever with copying symlinks. So, I upgraded the repo from my laptop (repo mounted with sshfs).
Note that this problem only occurs with adjusted branched, I also have other repos accessed and upgraded via sshfs (sometimes because I just ran "git status" on a repo mounted with sshfs, which resulted in an upgrade (I think)), and there is no file reported as modified (git status is also slow, though).
One note for people with the same issue: on my side, the file .git/info/attributes was missing.
I created it with the following content, taken from "git-annex help smudge" manpage:
And the "git status" issue vanished...
Well, I can confirm that, with .git/info/attributes missing,
git status
displays unlocked files as modified.But, the bug originally reported here had the files only start to show up as modified after some amount of time, not immediately. And also, it had
git diff --cached
outputting nothing when run on those files. The behavior with .git/info/attributes does not match either of those. So I don't think yours is the same problem as the original bug report. Which it's pretty clear involved sshfs.As to how .git/info/attributes could be missing: It is created by
git-annex init
. Upgrading a repository from v5 or older will also create it. So I don't see how it could normally be missing. At the moment the most likely reason would be if you had deleted it earlier..(One other way it can be missing is if annex.supportunlocked is set to false.)
Oh, I think oliv5 and guuex were the same person..
If you had .git/info/attributes missing all along, that nicely explains it all.
I think this can be closed then.