Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2014-07-16 14:17:59 -04:00
commit a2a9650514
10 changed files with 132 additions and 0 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
nickname="Jon Ander"
subject="comment 8"
date="2014-07-16T13:42:16Z"
content="""
I'm still having this issue in 5.20140709
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 9"
date="2014-07-16T18:08:26Z"
content="""
Are you sure that you have upgraded git-annex on every machine that uses that repository? You could have one old un-upgraded one still causing commits that would of course be visible on the rest.
Also, what version exactly does `git-annex version` show?
"""]]

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="divB"
ip="128.12.90.218"
subject="comment 3"
date="2014-07-15T22:02:41Z"
content="""
Update: You are right. It has nothing to do with the connections. I created a new repository without any sync. Same here:
[2014-07-15 13:53:33 Pacific Daylight Time] main: starting assistant version 5.20140715-g622a376
[2014-07-15 13:53:33 Pacific Daylight Time] Cronner: You should enable consistency checking to protect your data.
(scanning...) [2014-07-15 13:53:38 Pacific Daylight Time] Watcher: Performing startup scan
(started...)
git-annex: <stdin>: hGetLine: invalid argument (Bad file descriptor)
failed
git-annex: assistant: 1 failed
It always takes exactly 10 minutes until it dies (you see is started 13:53:33 and it died at 14:03:33 (=modification of daemon.log).
So this is reproduceable ...
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 4"
date="2014-07-16T18:18:11Z"
content="""
Hmm, there are two places where the assistant happens to hard code a 10 minute time period. But one is 10 minutes from starting to configure a ssh remote in the webapp, not from start. And the other is the watcher's afterLastDaemonRun check, which only happens when a symlink appears in the repository (which shouldn't happen on windows and wouldn't necessarily happen 10 minutes after start).
Fabulous .. I just reproduced the crash!
"""]]

View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="http://mildred.fr/"
ip="82.247.184.53"
subject="Fixing symlinks to the annex store in direct mode"
date="2014-07-16T06:52:33Z"
content="""
I have an issue with direct mode: I have tons of symlinks that points to the git-annex store, while in direct mode. After investigation, I found that these files don't seem to be part of the repository. I can check with:
$ git -c core.bare=false status --porcelain tr.html
?? Documentation/Mozilla/developer.mozilla.org/tr.html
$ ls -l tr.html
lrwxrwxrwx 1 mildred mildred 205 10 juin 16:22 tr.html -> ../../../.git/annex/objects/gF/z1/SHA256E-s31895--c873982bd742ba8db6e026afee26b7ab2f75f54f587304d8c2d877db3900c0f6.html/SHA256E-s31895--c873982bd742ba8db6e026afee26b7ab2f75f54f587304d8c2d877db3900c0f6.html
The link is valid, and is probably pointing to a unused file in the annex store. How to add these files back?
If I was in indirect mode, I could simply use `git add tr.html` (and **not** `git annex add`). This would stage to the git staging area the symlink, and all would be well.
I found that in direct mode, the same was true. The command is:
git -c core.bare=false add tr.html
The file is added to the repository, and the link is converted to the target file. The question now is why? There is no hook on the add command. Could it be the annex assistant? If that didn't worked, my question would have been: how to checkout a file in direct mode?
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://mildred.fr/"
ip="82.247.184.53"
subject="Re: Fixing symlinks to the annex store in direct mode"
date="2014-07-16T07:04:08Z"
content="""
What I said was just wrong. Instead of trying on tr.html, I tried with a copy of that file. But making the copy of that file had the wanted effect, transforming the symlink to the actual file. Probably the assistant monitoring file creation, and transforming indirect file to direct file. Or perhaps the `cp` command follows symlinks by default (I thought it didn't).
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 14"
date="2014-07-16T17:51:28Z"
content="""
I kinda wish people would post questions to the forum, and not clutter up this page..
Anyway, there have been past bugs in the direct mode code that caused some files to not be checked out in direct mode, but stay as symlinks pointing at the content. That can be fixed by running `git annex fsck`. But, I am not aware of any problem that can leave a git-annex symlink that is not checked into git at all. Perhaps you copied the symlink from another location?
"""]]

View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 1"
date="2014-07-16T18:18:00Z"
content="""
As soon as git-annex syncs with a remote that has made changes to the repository, any new files or files that have been modified, and the content is not yet available in the local repository will be broken symlinks. You can generally easily see a broken symlink by running `ls`, at least with a good `ls` on eg Linux that supports colorization. (Look for the red filenames.) Many file managers also represent broken symlinks in a visual way.
Or, you can run a command like `git annex whereis $file` and see if it includes \"here\" in the list of locations.
Or, you can run `git annex find --not --in here` to find all files whose current content is not present.
The reason `git annex status` doesn't say is that it's focused on showing you which files in the local repository have not yet been committed to git. The `git annex list` command has a similar one line per file output, but puts a \"_\" in the first column (under \"here\") if the file is not locally present.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 8"
date="2014-07-16T18:10:09Z"
content="""
git-annex only ever runs git from PATH; I never hardcode paths to programs.
You can verify this by running it with the --debug flag to see the exact commands it runs.
"""]]

View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkpIIYg6Fl7OFsOHVPEchZYj68A3dk4lVg"
nickname="Paul"
subject="text relocations refusal"
date="2014-07-16T02:19:27Z"
content="""
I'm afraid I've ruined the remote repo. For directory, I wrote \"mediashare\" because that's where I want copy to go. i don't want it in default \"annex\". In git assistant, it is unclearbwhst directory means. Mount point for cooy of remote?
Well, this is all I get now...
1|u0_a127@manta:/sdcard $ cd annex
u0_a127@manta:/sdcard/annex $ git annex status
WARNING: linker: git-annex has text relocations. This is wasting memory and is a security risk. Please fix.
"""]]