Recent comments posted to this site:

Thank you for the info! Will add the port grep to my auth grep script as you suggested.
Comment by markusk Wed Jul 23 23:18:37 2014

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.

Comment by joeyh.name Wed Jul 23 22:10:37 2014
Actually no, rsync was never run on the server. git-annex-shell looked to see if the file was present, and did not see the file.
Comment by joeyh.name Wed Jul 23 15:14:21 2014

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.

Comment by joeyh.name Wed Jul 23 15:05:36 2014
Assistant does not support SIGHUP. There is a menu item (top right menu) that can restart it.
Comment by joeyh.name Wed Jul 23 15:02:04 2014

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.

Comment by Adam Wed Jul 23 14:27:51 2014

Hi daniele,

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
manual
$ 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?

Comment by divB Wed Jul 23 05:20:47 2014

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.

Comment by daniele Tue Jul 22 02:10:14 2014

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.

Comment by daniele Tue Jul 22 01:47:29 2014

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.

Comment by daniele Tue Jul 22 00:29:20 2014