Comments in the moderation queue:
Recent comments posted to this site:
Support for --listen with a port was removed in version 5.20140306, since it was buggy. In particular, when the webapp creates a new repository, it needs to switch to a new port to serve that repository, so specifying a single port won't work.
Instead, when annex.listen or --listen specifies the address to listen on, git annex webapp will print out the url to use to open it, including the port it picked. This could be used in a script, or clicked on in the terminal to open a local browser when running the webapp on a remote host.
git annex webapp
This looks very much like rsync on the server crashed, possibly because of an error reading the file.
Accessing a git-annex repository over a network filesystem is almost never the best choice. Network filesystems are flakey at worst, and at best have locking problems and other limiations.
I tried to do the same from another local repository on the server and it worked fine.
I created a Linux VM and that also struggled, but this time with 57 errors.
It turns out that the way my files were being stored on the server was causing it. I had the files stored on a local NAS which was mounted via iSCSI. I moved the repository from the NAS to local storage and then did another clone and it is now working from the Linux VM and the Windows client via SSH. When using git annex get on the Linux VM it is much faster than the native Git bash which takes ages.
I am not completely sure what you mean but I as far as I understand as soon as I set "wanted" to anything other than "default" the standard groups do not apply at all.
I can't use vicfg because I use windows and this command hangs ... probably because there is no vi.
However, I can still check the expressions:
$ git annex group here
$ git annex wanted here
exclude="*" and present
Have you tried this? Does it work in your case?
Because the standard preferred contents also contains "present" so I assume it would behave the same.
Is maybe "present" broken or the behavior different than expected?
I was unsure as to what git-log command would best describe the problematic commits but in the meantime I did a:
git log --graph --decorate=full --full-diff
These are the only three commits of that afternoon (the surrounding history is from completely different hours and very likely unrelated, so it wasn't posted)
* commit d9eb9e94a3973598a847a5bdab1b65e459c1588a
| Author: COMPUTER B
| Date: Thu Jul 17 18:17:16 2014 +0200
* commit 6fa27f0849227c490ac4d4d62ca86e4befe5121e
| Author: COMPUTER A
| Date: Thu Jul 17 18:17:14 2014 +0200
* commit d25cc793739573057e475c92c8d37ce4ecc7bc9b
| Author: COMPUTER A
| Date: Thu Jul 17 18:17:12 2014 +0200
It's a straight line (fast forward?), I don't see any merging either. Is this normal? Shouldn't a change in Repo A bring a merge in Repo B (where everything stayed the same) when things are synchronized? I don't fully understand how annex syncs happen so don't mind this question if it's all normal.
I am not familiar with the log syntax shown
You mean the "git log --stat" part? Which git command would yield the most helpful syntax in this case?
AFAICS, the problem occurs on machine B. Which machine is the transcript from?
Sorry I forgot to mention it: yes, it's from machine B.
Is this "Removing" message then printed out by another git command?
Sorry I have no clue here. I didn't issue any git command from the terminal (nor did the user on computer A) if that was part of the question. It was all done in automatic.
Enabling debug logging would probably help a lot, to narrow that down the next time this occurs.
Will do. I'll set 'annex.debug' to true in .git/config. Sadly, computer A is (a laptop) on vacation at the moment (well outside the local network), so I'll have to wait a couple of weeks to get back to debugging this. I'll have the logs with debug enabled when it happens again.
Thanks again for your support and for developing git-annex.
wait, is the group working together with the preferred content?
Usually you set a repository in a group and then you tell annex that particular group has this preferred content expression (which by default is set to 'standard'). So you could add the repo to 'client' group then set the group 'client' to that preferred content expression. If you only want that particular client to have that expression you can play around with "groupwanted", or even define your own group I guess.
Use "git annex vicfg" to quickly check both "group" and "wanted" settings together.