code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.203"
 subject="comment 1"
 date="2014-06-18T18:12:47Z"
 content="""
So [[bugs/git-annex_auto_upgrade_is_redundant]] strikes again. I have fixed up the versions to avoid this upgrade loop again. I would rather discuss any problems with where the automatic upgrade code puts git-annex in a separate bug report than this one.. (If you're running git-annex as a user that is not allowed to write to the directory where you installed it in the first place then yes, it cannot write there and will instead unpack itself into the home directory.)

There are many strange things in the log, but this is probably the strangest:

> fatal: Could not switch to '/home/jwiklund/Documents/.git/annex/merge/': No such file or directory

This is the gitAnnexMergeDir used for direct mode merges. Since git-annex always creates that directory before starting a merge, I don't know how it could fail to exist.

Other strange things:

* The assistant fixes stale index.lock files on startup. But the log shows the assistant starting up and shortly thereafter there's a stale index.lock file. All I can think is that perhaps two git processes are trying to commit at the same time.

* \"fatal: pathspec 'music.txt' did not match any files\", apparently output by git-add.

* \"error: duplicate parent 294b61a3dce1e87a62e4d675deac2a9130b819e6 ignored\", which would happen if git-commit-tree were passed duplicate parent refs. AFAICS, the only place in git-annex that might do that is when it commits the git-annex branch. (While this says it's an error, it really is ignored, and git-commit-tree continues and makes a valid commit.)
"""]]

repo_name: kakafarm/git

license: unknown


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.2"
 subject="comment 2"
 date="2014-07-10T19:10:15Z"
 content="""
Looking back at this bug, it's clearly the same race that I later
debugged and fixed in [[bad_merge_commit_deleting_all_files]]. There are instructions in that bug for recovering it.

In particular, the \"fatal: Could not switch to '/home/jwiklund/Documents/.git/annex/merge/': No such file or directory\" is because of the race; the merge directory is being created and deleted by two contending threads.
"""]]


code:
I've had a bug report that the assistant follows directory symlinks to elsewhere. I thought it didn't. This needs to be avoided.

[[fixed|done]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.87"
 subject="comment 1"
 date="2013-12-18T18:22:49Z"
 content="""
Tried to reproduce this, and so far no luck. I tried several symlinks to outside ~/annex, in both direct and indirect mode, and neither the assistant's startup scan nor its inotify handling followed the links and added the content of the directory symlinked to.

I wonder if [[bugs/Symlinks_from_git-annex_repository_to_outside_git_repository_not_supported]] is the same problem. That seems to suggest this happens when merging the symlink into another repository. I am not clear on the details of how to reproduce it yet.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.87"
 subject="comment 2"
 date="2013-12-18T19:32:06Z"
 content="""
This was the same as the other bug, and only happened on OSX, in the startup scan.
"""]]


code:
### Please describe the problem.

it seems that `git annex forget --drop-dead --force` will double-encode UTF-8 characters.

### What steps will reproduce the problem?

Have a remote with an accent in the description.

### What version of git-annex are you using? On what operating system?

5.20140412 on debian jessie amd64.

### Please provide any additional information below.

[[!format sh """
anarcat@marcos:video$ git annex info
repository mode: indirect
trusted repositories: 1
        5adbab10-0f7a-467b-b0d8-5d7af2223103 -- here (backup (anarcat@marcos:/srv/video))
semitrusted repositories: 5
        00000000-0000-0000-0000-000000000001 -- web
        2d594c02-9164-4ebd-ac47-f8cdc9c16e2f -- rachel@topcrapn:~/Vidéos/anarcat
        2f90b958-95e4-44e3-8d3b-e780b63936d1 -- portable (300GB drive labeled VHS)
        96365189-a0b9-4c33-865f-b573d98572dc -- trouneslo@ifuckinglovecumputers:~/video-anarcat
        ae3d62e6-49be-4340-ba25-c8736a1637c4 -- anarcat@angela:~/video
untrusted repositories: 1
        f6a70cfe-0ee4-4762-9f1d-b7b545fbd856 -- External hard drive labeled VHS
transfers in progress: none
available local disk space: 14.29 gigabytes (+10 gigabytes reserved)
local annex keys: 4110
local annex size: 991.85 gigabytes (+ 2 unknown size)
annexed files in working tree: 4108
size of annexed files in working tree: 1.01 terabytes (+ 2 unknown size)
bloom filter size: 16 mebibytes (0.8% full)
backend usage:
        SHA256E: 8214
        URL: 4
anarcat@marcos:video$ git annex dead f6a70cfe-0ee4-4762-9f1d-b7b545fbd856
dead f6a70cfe-0ee4-4762-9f1d-b7b545fbd856 ok
(Recording state in git...)
anarcat@marcos:video$ git annex unused
unused . (checking for unused data...) (checking HEAD...) (checking synced/master...) (checking backup/master...) (checking portable/annex/direct/master...) (checking portable/master...) (checking portable/synced/master...) (checking steph/master...) (checking steph/synced/master...) (checking video/synced/master...) ok
anarcat@marcos:video$ git annex forget --drop-dead --force
forget git-annex (Recording state in git...)
ok
(Recording state in git...)
anarcat@marcos:video$ git annex info
repository mode: indirect
trusted repositories: (merging synced/git-annex backup/git-annex backup/synced/git-annex portable/git-annex portable/synced/git-annex steph/git-annex video/synced/git-annex into git-annex...)
(Recording state in git...)
(Recording state in git...)
1
        5adbab10-0f7a-467b-b0d8-5d7af2223103 -- here (backup (anarcat@marcos:/srv/video))
semitrusted repositories: 5
        00000000-0000-0000-0000-000000000001 -- web
        2d594c02-9164-4ebd-ac47-f8cdc9c16e2f -- rachel@topcrapn:~/VidÃÂ©os/anarcat
        2f90b958-95e4-44e3-8d3b-e780b63936d1 -- portable (300GB drive labeled VHS)
        96365189-a0b9-4c33-865f-b573d98572dc -- trouneslo@ifuckinglovecumputers:~/video-anarcat
        ae3d62e6-49be-4340-ba25-c8736a1637c4 -- anarcat@angela:~/video
untrusted repositories: 0
transfers in progress: none
available local disk space: 14.25 gigabytes (+10 gigabytes reserved)
local annex keys: 4110
local annex size: 991.85 gigabytes (+ 2 unknown size)
annexed files in working tree: 4108
size of annexed files in working tree: 1.01 terabytes (+ 2 unknown size)
bloom filter size: 16 mebibytes (0.8% full)
backend usage:
        SHA256E: 8214
        URL: 4
# End of transcript or log.
"""]]

well that's interesting - the above paste is broken by ikiwiki as well... in the text area where i paste it, "rachel@topcrapn:~/VidÃ©os/anarcat" shows up as "rachel@topcrapn:~/Vidéos/anarcat" but when i preview, the character gets corrupted. and obviously, the second instance then gets *double* corrupted - wheepee. the original paste has "rachel@topcrapn:~/VidÃÂ©os/anarcat". --[[anarcat]]

> [[fixed|done]]; writes to git-annex branch now preserve the original
> encoding, and I've tested that lots of interesting unicode is preserved
> across a forget run. --[[Joey]]


code:
[[!comment format=mdwn
 username="https://id.koumbit.net/anarcat"
 ip="72.0.72.144"
 subject="comment 1"
 date="2014-05-16T14:36:09Z"
 content="""
this eventually completely breaks with:

[[!format txt \"\"\"
anarcat@marcos:video$ git annex info --fast
repository mode: indirect
trusted repositories: 2
        31912b57-62a5-475c-87a7-582b5492a216 -- WD green 1.5TB backup drive
        5adbab10-0f7a-467b-b0d8-5d7af2223103 -- here (main (anarcat@marcos:/srv/video))
semitrusted repositories: 5
        00000000-0000-0000-0000-000000000001 -- web
        2d594c02-9164-4ebd-ac47-f8cdc9c16e2f -- rachel@topcrapn:~/Vid
git-annex: <stdout>: commitBuffer: invalid argument (invalid character)
failed
git-annex: info: 1 failed
\"\"\"]]
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.176"
 subject="comment 2"
 date="2014-05-27T17:58:35Z"
 content="""
Notice that the filename is corrupted from the beginning; all writes to the git-annex branch truncated characters to 8 bits. The rest just followed from that.
"""]]


code:
[[!comment format=mdwn
 username="https://id.koumbit.net/anarcat"
 ip="72.0.72.144"
 subject="comment 3"
 date="2014-05-29T16:09:38Z"
 content="""
awesome, thanks!
"""]]


code:
This tag is for bugs that have been forwarded from git-annex to some other
software, such as a library it uses.


code:
### Please describe the problem.
When a repository has no object of a given file and git annex fsck is run it still shows "fsck file ok", which is missleading in the sense, that it gives the impression that it checked the file is alright/checksummed.

As a result of this it seems that incremental fscks are not incremental with non checkable objects. On each run (after the first one) with "git annex fsck --incremental --more --schedule-limit 1d" all files without objects are checked even so it should wait another day till it checks again.

Probably best to say checksum couldn't be checked on x files (only give that as quiet output, not every check)

Another thing, which came up as a problem was, that checksum fsck would not be wanted to run as often as numcopie checks.
When the incremental fsck is used to check for bad files "git annex fsck --incremental --more --limit 1m" after a fast numcopies check "git annex fsck --incremental --more --limit 1m fast" it messes up the actual bad files check.
As both are currently using the same incremental "lock"-file they are colliding.

### What steps will reproduce the problem?
-

### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140210-gd99db49
Linux (Ubuntu 13.10)

### Please provide any additional information below.

[[!format sh """
# 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

# End of transcript or log.
"""]]

> [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="stp"
 ip="188.193.207.34"
 subject="Earlier version syntax was removed"
 date="2014-02-17T16:05:34Z"
 content="""
In earlier versions I noticed that when checksumming it would give back \"fsck file (checksum...) ok\" instead of \"fsck file ok\", which is at least better than not differentiating. This should definitely be improved. Perhaps even clearer than the (checksum...) notice.

But still the incremental run not being incremental and not taking into account the schedule-limit seems strange.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.172"
 subject="comment 2"
 date="2014-02-20T20:11:36Z"
 content="""
You're only meant to use one of --incremental, or --more, or --incremental-schedule at a time. I have made fsck refuse to accept combinations of those options.

What was happening is that, since you didn't understand the documentation (which is possibly not as clear as it could be; I have tried to improve it now), the --incremental option you passed dominated all the other options, and made it start a *new* incremental fsck each time. Which means it started from the beginning and fscked every file until you stopped it.

I agree that it would be better if fsck --fast --incremental did not collide with fsck --incremental. There is already a bug about that: [[incremental fsck should not use sticky bit]].

Finally, I agree that losing the \"(checksum)\" made fsck output less informative. Although I don't think it is needed in the `git annex add` output. I have made it be shown in only the fsck output.
"""]]


code:
[[!comment format=mdwn
 username="stp"
 ip="84.56.21.11"
 subject="Great improvements"
 date="2014-02-20T21:20:15Z"
 content="""
Thanks for clearing it up. It is still a bit confusing that you have to differentiate on the second run. (using --more) I probably view it as inconvenient as it make me have to remember the first and second time of running a command. I think it would be cleaner to have \"--incremental\" always skipping files and \"--incremental restart\" start from the beginning.

Ah great yeah they are different functions and should therefore not interfere. (fsck --fast --incremental)

Great that the checksum is back in and yeah I agree that it isn't really needed in the add command.

"""]]


code:
### Please describe the problem.
I followed the tip on [fully encrypted git repositories with gcrypt](http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/) to create encrypted git-annex repository on a ssh server. When I try to checkout the repository, things break as follows:

`git clone gcrypt::ssh://my.server/home/me/encryptedrepo myrepo`

works as expected but when in the myrepo directory,

`git annex enableremote encryptedrepo gitrepo=ssh://my.server/home/me/encryptedrepo`

issues the following text (among normal messages):

`git-annex-shell: gcryptsetup permission denied`

Then while the links are there,

`git annex get --from encryptedrepo`

does nothing (in the sense that the content is not retrieved).

This seems to have everything to do with git-annex-shell as the exact same manipulations but with a local repository work perfectly. Unfortunately, I don't know haskell so [this code](https://github.com/joeyh/git-annex/blob/master/Command/GCryptSetup.hs) is cryptic to me. I can guess there is a problem getting the uuid of the repository, but as far as I can tell the bare distant repo looks fine.

### What steps will reproduce the problem?

Create a standard git annex local repository and then follow the [fully encrypted git repositories with gcrypt tip](http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/) to create an encrypted git-annex repository on a ssh server. Then follow the instructions in the same tip to clone the remote repository.

### What version of git-annex are you using? On what operating system?
Both computers run ubuntu 12.04 with all updates and the latest git annex from the ppa, that is:

git-annex version: 4.20131024

build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP Feeds Quvi TDFA

key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL

remote types: git gcrypt S3 bup directory rsync web webdav glacier hook

### Please provide any additional information below.

[[!format sh """
# 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

# End of transcript or log.
"""]]

> [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.47"
 subject="comment 1"
 date="2013-11-02T19:46:28Z"
 content="""
It seems to me that the `git-annex-shell` on the remote system must be too old a version to support the gcryptsetup command. You can check this by running `git-annex-shell` there and seeing if it lists gcryptsetup in its usage message.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
 nickname="Fabrice"
 subject="comment 2"
 date="2013-11-02T21:53:37Z"
 content="""
The git-annex version on the remote server is the same as the one on the client, the latest one available from the ppa (4.20131024). When I run git-annex-shell on both computers, I obtain:
[[!format sh \"\"\"
git-annex-shell: bad parameters

Usage: git-annex-shell [-c] command [parameters ...] [option ...]

Plumbing commands:

commit       DIRECTORY          commits any staged changes to the git-annex branch
configlist   DIRECTORY          outputs relevant git configuration
dropkey      DIRECTORY KEY ...  drops annexed content for specified keys
gcryptsetup  DIRECTORY VALUE    sets up gcrypt repository
inannex      DIRECTORY KEY ...  checks if keys are present in the annex
recvkey      DIRECTORY KEY      runs rsync in server mode to receive content
sendkey      DIRECTORY KEY      runs rsync in server mode to send content
transferinfo DIRECTORY KEY      updates sender on number of bytes of content received
\"\"\"]]

Both sides seem to understand the gcryptsetup action. Actually, the message gcryptsetup permission denied comes from git-annex-shell, as far as I understand (and from the haskell source linked in the report).
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.47"
 subject="comment 3"
 date="2013-11-02T23:51:13Z"
 content="""
I should have looked at that error message more closely. The gcryptsetup command will print a permission denied if the repository it's being run in already has a annex.uuid or already has a gcrypt id. Probably that latter needs to be relaxed for enableremote to work.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.47"
 subject="comment 4"
 date="2013-11-03T00:15:30Z"
 content="""
While I've fixed this bug, in my testing the bug only caused git-annex to fall back to accessing the remote repository using rsync, rather than using git-annex-shell to talk to it, and so `git annex get --from encryptedrepo` was able to retrieve files that were stored in that remote despite the bug. That may have failed for you for some other reason.

You can set git.encryptedrepo.annex-gcrypt to to \"true\" to make it use the degraded rsync mode, or to \"shell\" to make it use git-annex-shell. Setting it to shell should be all that you need to do to recover from (or indeed, work around this bug).
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
 nickname="Fabrice"
 subject="comment 5"
 date="2013-11-03T11:24:28Z"
 content="""
There is something very strange that I did not notice in my first report. When I try `git annex get --from encryptedrepo` nothing happens in the sense that git annex is not even trying to connect to the remote (no ssh connection attempt) while git.encryptedrepo.annex-gcrypt is set to true. When I set it to shell, nothing happens either.

Another thing I did not report is that I tried the exact same manipulations with another server on which git annex is not installed. The `gcryptsetup permission denied` message was replaced by a `git-annex-shell not found` (or something similar), as expected. But the rest of the behavior was the same: no way to get the actual content with `git annex get --from`. Again, all of this is with 4.20131024, not with the ongoing version.

I'll try got do more test with the new version.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.47"
 subject="comment 6"
 date="2013-11-04T17:12:05Z"
 content="""
It's entirely normal for `git annex get --from remote` to skip files that it does not think are present on the remote.

What does `git annex whereis` say?
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
 nickname="Fabrice"
 subject="comment 7"
 date="2013-11-04T18:54:54Z"
 content="""
`git annex whereis` says the files are not on the remote git, while they are because of the copy. If I do _exactly_ what's on the tip, that is if I clone the encrypted git just after having done `git annex copy --to encryptedbackup`, the remotes seems to ignore that it has the data. To have it working, I had to call `git annex sync` (push will do, I guess) in the original remote after doing the `git annex copy`. Then I can `git pull` and `git annex whereis` knows where the files are (or I can clone the encrypted remote after doing the sync/pull).

It seems a bit strange that the copy command does not record the propagation of the file to the encrypted git. I guess this is because gcrypt is the only special remote that stores also the git part, right? Would that be a good idea (and possible) to handle it in a special way?

Thanks Joey for everything, by the way, both the software and the amazing support via email and the website.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.47"
 subject="comment 8"
 date="2013-11-04T19:14:04Z"
 content="""
Right -- Normally a special remote doesn't include a git repository. And when using a regular git remote, `git-annex-shell` is used to receive files into the repository and it records immediately that the repo has the file so there's no need to sync in that case. So gcrypt is special in this way.

For now, I have fixed the tip to show syncing after sending files to gcrypt. It might be the case that it would make sense to do a push of the git-annex branch automatically in that case, will have to think about that and see if people get tripped up on this.
"""]]


code:
### Please describe the problem.

When trying to create a repository—i.e., running it for the first time—I get this error message:

> user error (git ["--git-dir=(path)/.git","--work-tree=(path)","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"] exited 128)

It _seems_ that it's because the bundled `git` executable isn't used, and instead `/usr/bin/git` is; and it's too old to support the `--no-gpg-sign` flag.

### What steps will reproduce the problem?

Run `git-annex.app` for the first time and give it a path.

### What version of git-annex are you using? On what operating system?

    $ /Applications/Git-Annex.app/Contents/MacOS/git-annex version
    git-annex version: 5.20140707-gf0c48e8
    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external

### Please provide any additional information below.

`…/.git/annex/daemon.log` doesn't exist

    $ tree -a
    .
    ├── .DS_Store
    └── .git
        ├── HEAD
        ├── annex
        │   ├── index
        │   ├── misctmp
        │   ├── sentinal
        │   └── sentinal.cache
        ├── config
        ├── hooks
        │   └── pre-commit
        ├── objects
        │   ├── 4b
        │   │   └── 825dc642cb6eb9a060e54bf8d69288fbee4904
        │   ├── info
        │   └── pack
        └── refs
            ├── heads
            └── tags

> [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.55"
 subject="comment 1"
 date="2014-07-08T16:44:32Z"
 content="""
No, it's using it, it seems the version of git in the OSX build does not support that option.

I am going to fix the version problem, and update yesterday's OSX release with the fix.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawn0aWOz5xMj5VuexPl55h7IasQnsh7sVwE"
 nickname="Andy"
 subject="It works now"
 date="2014-07-08T22:47:07Z"
 content="""
You were right, it was an old git. I could have sworn it worked, but I must've got the versions mixed up because it didn't earlier.

Anyway, after updating, everything works fine. Thankyou!
"""]]


code:
### Please describe the problem.
git-annex will randomly crash.

### What steps will reproduce the problem?
Unknown. Keeping git-annex running for an extended period, failing to sync properly on XMPP(not sure if that is relevant, but given this haven't been found before it might be)

### What version of git-annex are you using? On what operating system?
git-annex version: 4.20130521-g20710d4 (And multiple prior versions)

### Please provide any additional information below.

.git/annex/daemon.log upload: http://paste.ubuntu.com/5694813/

I could find no debug.log?

> [[!taglink moreinfo]] until it's reproduced with a current version.. --[[Joey]]

>> Note that this seems like a similar untrappable crash as [[git_annex_daemon_crashes_when_authenticating_with_jabber.de]]. --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 nickname="joey"
 subject="comment 1"
 date="2013-05-24T15:50:45Z"
 content="""
I have seen this once on a similar system (family computer; XMPP being used). Unfortunatly it could be coming from anywhere -- and it's not at all clear how a crash in one thread could take it all down, since there are global top-level per-thread exception handlers that should run and log which thread crashed -- and normally seem to do this quite well.

I may need to make a management process that ensures the assistant stays alive.

I have also seen this happen when a computer is shutting down. But presumably in that case it's not really a bug.

One thing you might try is see what is using socket 16 when it's running, assuming the socket will be the same. (Also, if you've had repeated crashes, it would be good to know if it's 16 each time..). You could do this by looking at `/proc/$pid/fd/16` Also, check the old logs, `.git/annex/daemon.log.*`
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
 nickname="Tobias"
 subject="It did it again."
 date="2013-05-25T09:31:23Z"
 content="""
And this time it was socket 27.

Sadly happened during the night and I didn't monitor the socket when it happened.

"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 nickname="joey"
 subject="comment 3"
 date="2013-05-27T05:03:05Z"
 content="""
I got a similar crash:

<pre>
fd:19: hGetLine: end of file
fd:18: hFlush: resource vanished (Broken pipe)
fd:18: hFlush: resource vanished (Broken pipe)
</pre>

I was able to determine that fd 18/19 is reliably used for one of the git cat-file processes on this system. It's quite likely that fd 16/17 would be similar. fd 27 less likely. (But could easily be some other less long running git command.)

This would be consistent with git cat-file crashing as it's trying to write to it and read from it.

This took down the transferscanner thread, but the assistant continued running.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 nickname="joey"
 subject="comment 4"
 date="2013-05-27T15:31:53Z"
 content="""
I tried, as an experiment, killing on of the `git cat-file` child processes of the assistant. As hypothesized, that led to the same thing I saw logged before.

So, why might git commands be dying, and which commands? It would be pretty easy for git-annex to detect git cat-file dying, and restart it. Other commands would be more difficult. Still this might be a git bug which would best be fixed there. It would be good to get a core dump from git.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 nickname="joey"
 subject="comment 5"
 date="2013-05-31T18:17:59Z"
 content="""
It will now detect if any of the long-running git processes crash, and automatically restart them. I don't know if this addresses the crash that was originally reported.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 nickname="joey"
 subject="comment 6"
 date="2013-06-14T18:15:27Z"
 content="""
Tobias, have you seen this at all since the last release.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
 nickname="develop"
 subject="comment 7"
 date="2013-06-14T21:26:25Z"
 content="""
I'm sure i can still provoke it on some of my machines. But this weekend is completely blocked for me.

I'll update everything to latest and give you an updated log. But will probably not happen till the middle of next week.

"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
 nickname="develop"
 subject="comment 8"
 date="2013-06-29T09:34:02Z"
 content="""
I haven't been able to replicate this on two of my computers with the latest git-annex(as of this message).

It seemed to happen more on my Mac OS X Lion though. And nightlies haven't been build for some time.

So i'm waiting for a updated package for OS X. If you would rather clean up feel free to close this, I can just open it again if i hit it again.

"""]]


code:
### Please describe the problem.
git-annex crashes with "git-annex: createSession: permission denied (Operation not permitted)" when creating the first repository. Trying to start git-annex webapp after that crashes again.

### What steps will reproduce the problem?
* Download standalone tarball
* Unpack
* Go to new folder, call "git-annex webapp"
* Click Make repository

### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140606-g48793b6
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external

Ubuntu 14.04 LTS

Linux eee 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:02:19 UTC 2014 i686 i686 i686 GNU/Linux

### Please provide any additional information below.

[[!format sh """
# 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
$ git-annex webapp
Launching web browser on file:///tmp/webapp3414.html
git-annex: createSession: permission denied (Operation not permitted)
WebApp crashed: createSession: permission denied (Operation not permitted)
$
# End of transcript or log.
"""]]

> provisionally fixed; [[done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 1"
 date="2014-06-09T18:46:01Z"
 content="""
createSession just calls the unix `setsid` system call.

I have not been able to reproduce this problem using git-annex here. I suspect setsid is probably failing because git-annex is already a process group leader due to the way it was run. In this case, it should just ignore the setsid failure, which I've made it do.

This change will be available in the standalone tarball within an hour if you want to test it.

"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo"
 nickname="Dirk"
 subject="comment 2"
 date="2014-06-09T21:16:36Z"
 content="""
Thanks for the fix. The new tarball does not show the issue anymore.

Regarding \"due to the way it is run\":

* I use Konsole as my terminal under xfce, inside of that is bash
* I made sure that I removed old stuff beforehand \"rm -rf .config/git-annex/ Desktop/annex/ .ssh/git-annex-*\"
* I went to the directory in the tarball \"git-annex.linux\" and called \"./git-annex webapp\"
* Browser used is firefox

I guess I should setup the PATH properly. This was just meant as a test for the tarball given that there is no up to date package for ubuntu available anymore.

Not sure if there is other information that would help you determine if I run this in a special way.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawk9SYh6N-JUMkYkW4aOk55zC3Vr9KonDV4"
 nickname="Florian"
 subject="comment 3"
 date="2014-06-11T18:29:38Z"
 content="""
I'm having the exact same issue on Arch.

You said this fix was in the tarballs in one hour, which was almost two days ago. Are you refering to these downloads: http://downloads.kitenet.net/git-annex/linux/current/ I just wonder, because these show mtime of 5 days ago.

Thx!
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo"
 nickname="Dirk"
 subject="comment 4"
 date="2014-06-11T19:47:35Z"
 content="""
For me the autobuilt tarball works. Go to this page: http://git-annex.branchable.com/install/Linux_standalone/. Right before the comments start is a list of the different autobuilt tar balls.

I assume that this fix will appear in the regular tarballs with the next release.

Dirk

"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
 nickname="maurizio"
 subject="package in debian backports shows the same error mesage"
 date="2014-07-08T19:25:19Z"
 content="""
I upgraded recently (on wheezy) to package 5.20140529~bpo70+2 and when I to access the webapp I get:

    mezzo:~$ git-annex webapp
    git-annex: createSession: permission denied (Operation not permitted)

"""]]


code:
[[!tag moreinfo]]

### Please describe the problem.

git-annex webapp won't run

### What steps will reproduce the problem?

[[!format sh """
arthur@machine:~/annex$ git-annex --debug webapp
[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","show-ref","git-annex"]
[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","show-ref","--hash","refs/heads/git-annex"]
[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..a2b8f10ef258dff1a91e0354b2e2a58241631c9a","--oneline","-n1"]
error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..8d4b8e04ccf0092d625f680b42e73d7bf15c6517","--oneline","-n1"]
error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..6b2665208c11c9ecf969294bf45baac31894d8a7","--oneline","-n1"]
error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..9d8429668f2148ea43760fb430e5950fbf42751e","--oneline","-n1"]
error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
[2013-07-29 15:02:15 CEST] chat: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","cat-file","--batch"]

git-annex: fd:14: hGetLine: end of file
failed
[2013-07-29 15:02:15 CEST] read: ssh ["-O","stop","-S","/home/arthur/annex/.git/annex/ssh/arthur@git-annex-hostname-arthur_annex","-o","ControlMaster=auto","-o","ControlPersist=yes","arthur@git-annex-hostname-arthur_annex"]
git-annex: webapp: 1 failed
"""]]

### What version of git-annex are you using? On what operating system?

$ git-annex version
git-annex version: 4.20130516.1
build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
local repository version: 3
default repository version: 3
supported repository versions: 3 4
upgrade supported from repository versions: 0 1 2

$ git --version
git version 1.7.9.5

### Please provide any additional information below.


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.21"
 subject="comment 1"
 date="2013-07-30T19:00:43Z"
 content="""
You have a somewhat out of date version there. Can you please try again with a newer version? There have been several fixes to bugs that could present like this.
"""]]


code:
What steps will reproduce the problem?
 Start "./git-annex-webapp"

What is the expected output? What do you see instead?
 The webapp should start, but I get the error "git-annex: getUserEntryForID: failed (Success)"

What version of git-annex are you using? On what operating system?
 3.20121017 on "Ubuntu 10.04.4 LTS" 32-Bit

Please provide any additional information below.

> [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.118"
 subject="comment 1"
 date="2012-10-25T18:52:52Z"
 content="""
This means it has been unable to look up your home directory in /etc/passwd. I wonder, are you using NIS or a similar thing that keeps your user entry out of /etc/passwd?
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
 nickname="Tobias"
 subject="comment 2"
 date="2012-10-25T21:29:05Z"
 content="""
Yes, the system is using LDAP as user backend... Any idea how I can use git-annex with LDAP as user backend?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.118"
 subject="comment 3"
 date="2012-10-25T22:18:55Z"
 content="""
Well, git-annex needs to know the user name, and the home directory. I've made it use
USER, and HOME, when set, and only fall back to getpwent otherwise.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
 nickname="Tobias"
 subject="comment 4"
 date="2012-10-26T05:49:47Z"
 content="""
I think you mean the environment variables with \"use USER, and HOME\"? So I checked them I they are correct.
Reading man(3) getpwent says \"from the password database (e.g., the local password file /etc/passwd, NIS, and LDAP)\", so it should be no problem with the LDAP backend I'm using to log-in...
One other special thing: The home directory is on a NFS share.
"""]]


code:
### Please describe the problem.

The git-annex annex repo at <https://downloads.kitenet.net/.git/> is not available. This is the address mentioned at <http://git-annex.branchable.com/publicrepos/>.

### What steps will reproduce the problem?

    $ git clone https://downloads.kitenet.net/.git/
    Cloning into 'downloads.kitenet.net'...
    fatal: repository 'https://downloads.kitenet.net/.git/' not found

### Please provide any additional information below.

Have tried various combinations of the URL, but nothing works. It was like this a week ago too, but I didn't report it because I thought it was a temporary error due to some server reconfiguration or something.

[[!format sh """
# 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

# End of transcript or log.
"""]]

> [[fixed|done]] --[[Joey]]


code:
### Please describe the problem.

Hi,

On OSX the web-app keeps notifying me of an upgrade, I choose to run it but nothing seems to happen.

The debug logs show that the upgrade is skipped as it's redundant.

### What steps will reproduce the problem?

Have upgrades set to notify.

### What version of git-annex are you using? On what operating system?

Current.

### Please provide any additional information below.

[[!format sh """
# 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
[2014-04-25 08:26:30 BST] Upgrader: An upgrade of git-annex is available.  (version 5.20140421)
[2014-04-25 08:27:02 BST] main: Skipping redundant upgrade

# End of transcript or log.
"""]]

[[!meta title="upgrade loop when info file contains newer version than distributed version of git-annex"]]

[[!tag confirmed]]

> [[fixed|done]]; the release process now uses versions from build-version
> files that are created by the autobuilders, so should always be accurate.
> --[[Joey]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
 nickname="Matt"
 subject="comment 1"
 date="2014-04-25T07:36:09Z"
 content="""
The upgrade notifications seem to appear when switching between repositories in the web-app - are repositories treated separately?  Or perhaps notifications sent per repo?

"""]]


code:
[[!comment format=mdwn
 username="https://id.koumbit.net/anarcat"
 ip="72.0.72.144"
 subject="comment 2"
 date="2014-04-25T13:25:43Z"
 content="""
i think this problem was quickly mentionned in [[devblog/day_157__upgrade_checking]], can you provide a full debug log?
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
 nickname="Matt"
 subject="comment 3"
 date="2014-04-26T20:26:35Z"
 content="""
I'm pretty sure that was the sum total of the log (even with debug on).  Only the brevity of it makes me doubt myself.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.114"
 subject="comment 4"
 date="2014-04-27T00:02:41Z"
 content="""
What version of git-annex do you have running?

I suspect that if you look around, you will find you have a git-annex-5.20140421 directory in either your home directory or next to where you installed the DMG.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
 nickname="Matt"
 subject="comment 5"
 date="2014-04-27T11:10:49Z"
 content="""
Hi,

Yes there is a git-annex.app.5.20140421 directory in $HOME.  And it looks as though I'm running git-annex.app.5.20140420 - even though I manually tried to upgrade by downloading

https://downloads.kitenet.net/git-annex/OSX/current/10.9_Mavericks/git-annex.dmg

Running `$HOME/git-annex.app.5.20140421/.../git-annex` gives me `5.20140420-ga25b8bb`.  So the downloaded version even though labeled 5.20140421 contains 5.20140420.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
 nickname="Matt"
 subject="comment 6"
 date="2014-04-27T11:14:40Z"
 content="""
And I still think there is a slight bug in there somewhere.  If due to packaging errors an upgrade doesn't apply and the logs are smart enough to notice it's redundant then there shouldn't be continued notifications of an available upgrade...
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 7"
 date="2014-05-16T17:54:38Z"
 content="""
I've temporarily worked around this by updating the .info file for OSX to have the right version number.

I think that my release process generally manages to avoid version skew, but not always. And it's most likely to happen for OSX since that autobuilder only runs once per day.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
 nickname="Ovidiu"
 subject="comment 8"
 date="2014-05-16T18:00:18Z"
 content="""
So what do we as end-users do to get the latest version now? Re-download?
"""]]


code:
### Please describe the problem.

I have found a really weird commit in my git-annex branch:

    * a59dd1c update (il y a 8 heures) <Antoine Beaupré>
    * 57f887a update (recovery from race) (recovery from race) (recovery from race) [...]

it repeats that for a looong time. about 12 000 times, to be more precise:

[[!format sh """
anarcat@marcos:video$ git show 57f887a | wc
      5   12686   88850
"""]]

### What steps will reproduce the problem?

Now i have absolutely no idea how I managed that. I got through some pretty dark moments last night trying various levels of git-annex voodoo (including a duplicate repo which was rsync'd to a backup drive so the unique identifier applied to two distinct paths), so I have no idea exactly what happened here.

### What version of git-annex are you using? On what operating system?

debian jessie amd64 5.20140412

### Please provide any additional information below.

[[!format sh """
anarcat@marcos:video$ git show 57f887a | tail -c 100
very from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
anarcat@marcos:video$ git show 57f887a | head -c 512
commit 57f887a9d766829d00832ad1ee23b2785212d055
Author: Antoine Beaupré <anarcat@koumbit.org>
Date:   Sat Apr 19 01:48:18 2014 -0400

    update (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery
"""]]

that's 80KB for only one commit here - maybe that should be cleaned up? --[[anarcat]]

Ah! more information: it seems that 01:48 was the moment i shutdown the assistant in yet another panic...

[[!format sh """
anarcat@marcos:video$ ls -al .git/annex/daemon.log*
-rw-r--r-- 1 anarcat anarcat  17075 avril 19 09:28 .git/annex/daemon.log
-rw-r--r-- 1 anarcat anarcat 128367 avril 19 01:48 .git/annex/daemon.log.1
"""]]

an extract from that second logfile:

[[!format sh """
19/Apr/2014:01:31:38 -0400 [Error#yesod-core] unknown response from git cat-file ("9a73bf01-ed01-450d-a0ab-f20fff47ed32 encryption=none name=stephc rsyncurl=192.168.0.104:video/ type=rsync timestamp=1397865844.925354s","refs/heads/git-annex:remote.log") @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
19/Apr/2014:01:31:50 -0400 [Error#yesod-core] unknown response from git cat-file ("fe428a7a-25a2-4c2e-b01f-315c490cbe45 encryption=none name=myrsync rsyncurl=/home/anarcat/video/ type=rsync timestamp=1397868063.038898s","refs/heads/git-annex:remote.log") @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
19/Apr/2014:01:31:57 -0400 [Error#yesod-core] unknown response from git cat-file ("","refs/heads/git-annex:remote.log") @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
[2014-04-19 01:32:03 EDT] TransferScanner: Syncing with test, mnt
Depuis /mnt/video
 * [nouvelle branche] synced/git-annex -> test/synced/git-annex
 * [nouvelle branche] synced/master -> test/synced/master
fatal: 'mnt' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Already up-to-date.
[2014-04-19 01:32:21 EDT] main: warning git-annex has been shut down

(Recording state in git...)
(Recording state in git...)
(Recording state in git...)
(Recording state in git...)
"""]]

the last line repeats about 4000 times.

i would love to paste the daemon.log.1 file, but it seems like it containts encryption credentials... which i have no idea how to get rid of or change.

[[!tag moreinfo]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.191"
 subject="comment 1"
 date="2014-04-20T17:11:02Z"
 content="""
Is there one commit with this long message, or 12 thousand commits each adding another (recovery from race) to the pyramid?

<pre>
 - Also safely handles a race that can occur if a change is being pushed
 - into the branch at the same time. When the race happens, the commit will
 - be made on top of the newly pushed change, but without the index file
 - being updated to include it. The result is that the newly pushed
 - change is reverted. This race is detected and another commit made
 - to fix it.
</pre>

If there is only one message, then it must have tried 12k times to commit to the git-annex branch and each time something else pushed or commited to the git-annex branch and overwrote its commit. This seems statistically unlikely. (Also there's locking to prevent multiple local git-annex processes from committing at the same time.)

There have been a few other unexplained reports of this race detection code repeatedly triggering.

> \"shutdown the assistant in yet another panic\"

This implies some hasty, perhaps unusual shutdown method, and some unusual situation. I think you could tell me more about what was going on.
"""]]


code:
[[!comment format=mdwn
 username="https://id.koumbit.net/anarcat"
 ip="72.0.72.144"
 subject="comment 2"
 date="2014-04-20T23:58:00Z"
 content="""
this was a single commit.

i am not sure i can extract much more information from my memory: details are hazy as i was working late on a problem that night... sorry!
"""]]


code:
As per [[install/Android/#comment-e218073735d67691a2c3f66cc53ca6ac]] and [[install/Android/#comment-29bd13ab9cb830ffcd7850b84fb111c8]] :

git-annex is broken on Android 4.3; both on Nexus 4 and Nexus 7.

> [[Fixed|done]]. A 4.3 build of the apk is now available.
> (Unfortunately the fix breaks support for older versions of Android,
> so two versions of the apk have to be built now.) --[[Joey]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawm7qEQF8yzbY0_PHq3QERHxUGuXmW6qw8o"
 nickname="Anton"
 subject="comment 10"
 date="2013-11-10T22:10:49Z"
 content="""
I can confirm that the Hello World program works with the Nexus 7 2013, running Android 4.3.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="Hooray!"
 date="2013-11-10T22:21:46Z"
 content="""
I have a Nexus 7 (2013) with 4.3 that I'll test it on---I expect that my test will be successful.

I'll also run the test on my Nexus 5, running 4.4.

Getting git-annex working on 4.3 was the last thing keeping me from being able to ditch Dropbox entirely.  I'm so glad to hear there's some potential progress.

"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 12"
 date="2013-11-10T22:23:49Z"
 content="""
Full rebuild in progress (takes about 6 hours +- manual fixing).
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="Oh, and if a 4.3 device would be helpful..."
 date="2013-11-10T22:28:48Z"
 content="""
I have Samsung Epic 4G (epic_mtd) that I'm no longer using and would be quite happy to send you---it's older, and slow, but it is at least currently supported by CyanogenMod, so it should be possible to install 10.2 milestone builds on it and at least do basic testing.

Hell, if it would really facilitate Android support, I'd happily pick up something like a B&N Nook HD+ and send it to you---that should be similarly amenable to CM installs and testing.

Though I will also understand if you don't necessarily want to have a bunch of superfluous hardware laying around.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="Works on KitKat"
 date="2013-11-10T23:15:28Z"
 content="""
I skipped testing on my Nexus 7, figuring that would be duplicative, and instead ran it on my Nexus 5, and it worked great.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 15"
 date="2013-11-11T04:34:21Z"
 content="""
6 hours later, and: <http://downloads.kitenet.net/git-annex/autobuild/android/git-annex.apk>

testing appreciated!
"""]]


code:
[[!comment format=mdwn
 username="https://launchpad.net/~subito"
 nickname="subito"
 subject="Nexus 5 Android 4.4"
 date="2013-11-11T10:07:07Z"
 content="""
Does not work for me. Same error as in the original Bug report.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="Same error as before, Nexus 5 and 7"
 date="2013-11-11T13:06:17Z"
 content="""
Unfortunately, my experience mirrors subito's---same error as before on both 4.3 and 4.4.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 18"
 date="2013-11-11T13:27:49Z"
 content="""
Hmm, maybe the problem is caused by stripping the program? If so, this should fail the same way: <http://tmp.kitenet.net/hello.stripped>
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="Unfortunately, it would not appear that easy..."
 date="2013-11-11T14:33:05Z"
 content="""
The stripped binary for hello worked fine.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.21"
 subject="comment 1"
 date="2013-07-30T17:31:53Z"
 content="""
Given that the issue is it can't link against libc, it may need to be rebuilt with a newer version of the Android SDK and/or NDK.

OTOH, for it to get as far as it does, the start.c has successfully run, using the system's libc. So perhaps this only affects Haskell binaries somehow?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 20"
 date="2013-11-11T16:23:11Z"
 content="""
To bisect the problem space further, in case the apk build machinery is at fault, here's a git-annex binary not included in an apk. (Run same as the hello world.)

<http://tmp.kitenet.net/git-annex.bin>

And here's a more minimal git-annex binary (trying to look identical to hello world from the linker's perspective, just a bit larger..).

<http://tmp.kitenet.net/git-annex-min.bin>
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
 nickname="Sören"
 subject="Galaxy S4 Android 4.3"
 date="2013-11-11T18:47:23Z"
 content="""
hello and hello.stripped both work here but the git-annex binaries don't (still the same error as in the bug report).
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="Both fail..."
 date="2013-11-11T18:53:34Z"
 content="""
Same linking issue for both.

I don't *think* it should make any difference at all, but to spare myself a little bit of typing on this soft keyboard, I'm using a small variation on your script; I'm sharing it so other testers can use it, too, and so someone can point out if I'm doing something wrong:

    D=/data/data/ga/androidterm/tmp/gatest
    cp <file> $D
    chmod +x $D
    $D

"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 23"
 date="2013-11-11T19:14:59Z"
 content="""
Script variation is ok.

So, it's looking like perhaps a problem with the way cabal links the executable, which I notice is a two stage process, vs the way ghc links it with --make.

To narrow down, here is hello built using cabal:

<http://tmp.kitenet.net/hello-cabal>

Here is git-annex built not using cabal:

<http://tmp.kitenet.net/git-annex-byhand>

(For my own reference, it's also built without WITH_CLIBS.)
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
 nickname="Sören"
 subject="comment 24"
 date="2013-11-11T19:56:04Z"
 content="""
hello-cabal working, git-annex-byhand not.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="I got the same results as Sören."
 date="2013-11-11T20:37:08Z"
 content="""
cabal doesn't seem to be the culprit.

"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="finally getting debugger spun up"
 date="2013-11-12T01:08:24Z"
 content="""
<https://code.google.com/p/android/issues/detail?id=28598> seems relevant (and the patches to fix it seem likely to have led to the linker rejecting this).

So I can probably stop torturing your soft keyboards. I need a binary where `arm-linux-androideabi-4.8/bin/arm-linux-androideabi-readelf -r` does not contain `R_ARM_COPY`. Checking against the binaries so far, this consistently matches the test results, all the git-annex binaries have:

<pre>
 Offset     Info    Type            Sym.Value  Sym. Name
011d05f0  00004e14 R_ARM_COPY        011d05f0   environ
</pre>

(Which is itself interesting; I've had to work around some problems with the haskell port not supporting getting the environment (Annex.Branch.withIndex). Possibly because it was copied and the linker screwed that up? <https://github.com/neurocyte/ghc-android/issues/7>)

Ok, here's a binary that meets those criteria. Obtained by passing -z nocopyreloc to the gold linker (ghc options -optl-z -optlnocopyreloc)

<http://tmp.kitenet.net/git-annex-nocopy>

Also, here's a hello world binary that *should* fail. It attempts to read and print the environment, and has the same `R_ARM_COPY` relocation.

<http://tmp.kitenet.net/hello-env-copy>

And, here's a hello world binary that *might* successfully print out the full environment (like `set` does). If it does, I can also remove the ugly hack in Annex.Branch.withIndex. Which would be an unexpected reward.

<http://tmp.kitenet.net/hello-env-nocopy>
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="nocopy variants work!"
 date="2013-11-12T03:17:09Z"
 content="""
I tested both the hello-env-nocopy and the git-annex-nocopy binaries successfully.  hello-env-copy failed as you predicted.

Yay!
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 28"
 date="2013-11-12T03:58:56Z"
 content="""
This fix is now in place in the android autobuilds.

Just to be sure, hello-env-nocopy managed to print out multiple environment variables?
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
 nickname="Sören"
 subject="APK now works too"
 date="2013-11-12T09:10:49Z"
 content="""
I got the same results as Michael. The output of hello-nocopy is a longer list of environment variables.
Even better, the apk from the autobuilder now seems to work fine as well, including the webapp.
Great work! Thanks for digging into this.
"""]]


code:
[[!comment format=mdwn
 username="http://edheil.wordpress.com/"
 ip="173.162.44.162"
 subject="comment 2"
 date="2013-08-28T13:54:00Z"
 content="""
On a stock Nexus 7 running the latest OS (4.3), this is still the case as of release 4.20130827.

    Falling back to hardcoded app location; cannot find expected files in /data/app-lib
    git annex webapp
    u0_a18@grouper:/sdcard/git-annex.home $ git annex webapp
    CANNOT LINK EXECUTABLE: git-annex invalid R_ARM_COPY relocation against DT_SYMBOLIC shared library libc.so (built with -Bsymbolic?)
    1|u0_a18@grouper:/sdcard/git-annex.home $
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnegApaT6kTI0Gxy9SNmI9Og-k_fC_aS7Y"
 nickname="Michael Alan"
 subject="Yep, the env was printed"
 date="2013-11-12T10:18:56Z"
 content="""
I would recognize the output of a Show instance anywhere.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkgedYqmQb4dJU7UdVuRLwsQE-KlKVrFto"
 nickname="Chungy"
 subject="comment 3"
 date="2013-09-01T00:25:15Z"
 content="""
Just confirming the bug on my Verizon Galaxy S 3 with CyanogenMod 10.2 (Android 4.3), it's not Nexus-specific.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawntVnR-Z5ghYInvsElbDeADPSuCsF18iTY"
 nickname="Thomas"
 subject="comment 4"
 date="2013-09-01T20:02:59Z"
 content="""
Yet another confirmation of the bug on a Samsung Galaxy Note running 4.3 via Cyanogenmod as well.
"""]]


code:
[[!comment format=mdwn
 username="http://edheil.wordpress.com/"
 ip="173.162.44.162"
 subject="comment 5"
 date="2013-09-03T14:38:51Z"
 content="""
If there's anything we can do to help debug this, please let us know.  Have just started using git-annex on android recently & would love to have it on all my devices.

"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0"
 nickname="Matthew"
 subject="Definitely broken Galaxy Nexus GSM 4.3"
 date="2013-09-12T11:11:34Z"
 content="""
Definitely broken in 4.3, stock Galaxy Nexus GSM \"maguro\" release `2013-09-09 12:46`
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawknwkXgi8SnK4QT32ANl3GMKvFLyQGeHqo"
 nickname="Florian"
 subject="comment 7"
 date="2013-10-08T16:18:07Z"
 content="""
Any comment from on this from one of the maintainers would be great. Apparently this was not fixed in the latest (2013-10-02 18:46) build.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA"
 nickname="Joe"
 subject="Samsung Galaxy S4 also affected"
 date="2013-11-09T02:47:54Z"
 content="""
Verizon just pushed out 4.3 to Samsung Galaxy S4 devices. This issue is affecting me now too.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 9"
 date="2013-11-10T20:12:47Z"
 content="""
I have finally managed to get ghc to build with the newest version of the NDK. I hope this means it will make binaries that work with 4.3, but I don't have a device to test.

Here is a hello world program built with it:
<http://tmp.kitenet.net/hello>

After downloading it to an Android device, you can test it by opening the
git-annex terminal, and running: `D=/data/data/ga.androidterm/tmp; cp hello $D; chmod +x $D/hello; $D/hello`

Tested working on android 4.0.4

Also, I have filed a bug upstream about this at <https://github.com/neurocyte/ghc-android/issues/23>
"""]]


code:
### Please describe the problem.

umask is 022 on both hosts
If one does ls -lL on source repo, the files are shown 644.

Now, "git annex get" from a clone done over ssh generally preserves 644 ... except if the transfer (rsync) is interrupted, and then resumed.
In fact, looks like the temp files in .git/annex/tmp have the og+r bits cleared during the resumed transfer.

So this is inconsistent: I don't see why permissions should be different, depending whether or not there was an interruption in the transfer.
Plus, og+r permissions can actually be important for setups like serving contents using Samba.

### What steps will reproduce the problem?

    cd dir1
    git init
    git annex init
    touch a
    truncate -s 10G b
    git annex add .
    git commit -m 'new'

    git clone localhost:/path/to/dir1 dir2
    cd dir2
    git annex get
    ctrl^c
    git annex get
    ls -lL
    ... see different perms

### What version of git-annex are you using? On what operating system?

git-annex version: 5.20140411-gda795e0
Linux

### Please provide any additional information below.

[[!format sh """
# 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

# End of transcript or log.
"""]]

> [[fixed|done]]; brought back -p on non-crippled file systems --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.191"
 subject="comment 1"
 date="2014-04-17T18:32:40Z"
 content="""
(I think you forgot to mention you were using direct mode.)

Like git, git-annex does not preserve file permissions. If you want to ensure that a group or everyone can read file in a git repository, you have to use the core.sharedRepository git configuration. git-annex will also honor that.

git-annex will try to preserve the execute bit, since git does support that single permission bit. But even this cannot be guaranteed. (Eg, when using special remotes which have no concept of file permissions.)

Interrupting rsync and resuming it does cause rsync to not transfer through permissions. This is rsync's normal behavior when not using -p. git-annex used to use rsync -p to preserve whatever file permissions there were. However, <http://bugs.debian.org/700282>, and then [[!commit f92eaf631509d02491c1b0ebfbb15145f80df797]].

It looks like I could preserve the execute bit across interrupt and resume by using rsync's --executability option.

Or, I could use the -p when git-annex is running in a non-crippled filesystem.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
 nickname="Michael"
 subject="comment 2"
 date="2014-04-17T21:19:10Z"
 content="""
Hi Joey,

In fact, this is indirect mode on Linux, ext4.
I'm less worried about preserving +x mode (though I can see why it would be useful). Here I'm referring to plain \"group\" and \"other\" read permissions being cleared.

And I just did a test with a standalone rsync, using rsync -P localhost:file file2 and interrupting it, the partial (and final after resume) file2 still is 644 (and not 600 like in git-annex case).
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
 nickname="Michael"
 subject="comment 3"
 date="2014-04-17T21:19:59Z"
 content="""
I think -p on non-crippled does make sense, and -E does too for crippled.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
 nickname="Michael"
 subject="comment 4"
 date="2014-04-17T21:22:16Z"
 content="""
s/and not 600/and not 400/

In my ideal case I'd like to see indirect git-annex to set files to 444 (if umask in destination doesn't prevent that otherwise).
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
 nickname="Michael"
 subject="comment 5"
 date="2014-04-17T21:32:35Z"
 content="""
core.sharedRepository does fix things here. Thanks Joey!
I'm all set for my use case.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
 nickname="Michael"
 subject="comment 6"
 date="2014-04-18T18:32:22Z"
 content="""
One issue (bug) still remains: git annex does respect

sharedRepository = world

but not

sharedRepository = 0644

In the later case, with indirect mode, files end up with 400 permissions.

"""]]


code:
### Please describe the problem.

Installing on Windows requires installing git followed by git-annex.
Installing the former works without admin rights, but the latter cannot be
installed afterwards.

### What steps will reproduce the problem?

1. Create a Windows account without admin rights
2. Install git
3. Install git-annex

### What version of git-annex are you using? On what operating system?

Latest release on MS Windows.

### Please provide any additional information below.

Installing git creates read-only directories that cannot be used by the
git-annex install afterwards. Without admin rights, the read-only flag of
the git dir cannot be altered.

[[!tag confirmed]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.64"
 subject="comment 1"
 date="2013-11-26T16:19:41Z"
 content="""
Thanks, this had been reported in the forum before, but they did not point at the directory permissions as the problem.

It would be possible to modify the installer to install git-annex somewhere else and add it to the PATH, but it seems this is a utter nightmare on windows and I'd have to pull in enormous NSIS scripts from their wiki, of unknown provenance. Which is why I am piggybacking on the git installation's PATH.
"""]]


code:
[[!comment format=mdwn
 username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
 nickname="Frederik Vanrenterghem"
 subject="comment 2"
 date="2013-11-26T21:57:28Z"
 content="""
Just wondering how git succeeds in installing as non-admin user. The folder it goes in is also read-only.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.87"
 subject="comment 3"
 date="2013-12-12T19:33:50Z"
 content="""
I've made the installer now request admin rights if run by a non-admin. Hopefully good enough. However, the NSIS docs say that only works on Vista or higher. The old XP I'm using (that will be completely EOLed soon IIRC) still has the problem.
"""]]


code:
### Please describe the problem.

### What steps will reproduce the problem?

$ git init
Initialized empty Git repository in /cygdrive/c/Temp/.git/

$ git-annex init
init
  Detected a filesystem without fifo support.

  Disabling ssh connection caching.

  Detected a crippled filesystem.

  Disabling core.symlinks.

  Enabling direct mode.
fatal: You are on a branch yet to be born
git-annex.exe: git [Param "checkout",Param "-q",Param "-B",Param "annex/direct/master"] failed

$ git checkout -B annex/direct/master
fatal: You are on a branch yet to be born

### What version of git-annex are you using? On what operating system?

Running under cygwin bash

$ git --version
git version 1.7.9

$ git-annex version
git-annex version: 5.20140421-g78d6aa1
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external

> [[fixed|done]]; documented the needed version of git on the windows
> install page. --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.114"
 subject="comment 1"
 date="2014-04-27T00:13:49Z"
 content="""
This looks similar to [[bugs/git-annex_fails_to_initialize_under_Windows]], which was solved by upgrading to a newer version of msysgit.

git 1.7.9 is extremely old (years). Probably the empty commit that is done when switching to direct mode, precisely to avoid this problem, fails, because the pre-built git-annex for windows is targeting a modern version of git, from msysgit.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkYmMFDdf3GJ9Oba6NCVkzGc4JyB9WavMs"
 nickname="Xinruo"
 subject="comment 2"
 date="2014-04-27T11:58:13Z"
 content="""
OK installing git 1.9.2 from msysgit solves the problem. I thought I have read somewhere that you used cygwin for Windows development and didn't know that git from cygwin is too old. Thanks for the help!
"""]]


code:
### Please describe the problem.
Starting the webapp fails if the Nautilus scripts directory doesn't exist.

### What steps will reproduce the problem?

[[!format sh """
$ mv ~/.local/share/nautilus ~/.local/share/nautilus.bak
$ git-annex webapp

git-annex: /home/brunksn/.local/share/nautilus/scripts/git-annex get: openFile: does not exist (No such file or directory)
failed
git-annex: webapp: 1 failed
"""]]

### What version of git-annex are you using? On what operating system?
5.20140402, Debian testing

### Please provide any additional information below.

Workaround for users without Gnome/Nautilus:
[[!format sh """
$ mkdir -p ~/.local/share/nautilus
"""]]

It seems git-annex tries to create the scripts without checking if the actually directory exists. One solution would be to just create it if it doesn't exist or to only write the scripts if it exists already. Patch for the latter below. Works for me but my haskell knowledge is still very limited.

By the way, what is the preferred way to contribute patches for git-annex? I couldn't find any information about that on the website.

[[!format diff """
diff --git a/Assistant/Install.hs b/Assistant/Install.hs
index 4d02c0e..883ca48 100644
--- a/Assistant/Install.hs
+++ b/Assistant/Install.hs
@@ -87,8 +87,9 @@ installNautilus :: FilePath -> IO ()
 #ifdef linux_HOST_OS
 installNautilus program = do
        scriptdir <- (\d -> d </> "nautilus" </> "scripts") <$> userDataDir
-       genscript scriptdir "get"
-       genscript scriptdir "drop"
+       whenM (doesDirectoryExist scriptdir) $ do
+               genscript scriptdir "get"
+               genscript scriptdir "drop"
   where
        genscript scriptdir action =
                installscript (scriptdir </> scriptname action) $ unlines
"""]]

> [[applied|done]]. thanks! That's a fine way to send a small patch, or
> make a git branch somewhere for a larger one. --[[Joey]]


code:
### Please describe the problem.

Running `git annex group here manual` and `git annex group here client` results in the nonsensical group of "manual client".  Should there be checking for the reserved "standard" group words?

The intention from the webapp and docs reads as though these groups should be mutually exclusive.

Also it would be nice if `git annex group here` returned the list of groups (I put this as a wishlist item but think it perhaps warrants a bug mention).

### What steps will reproduce the problem?

### What version of git-annex are you using? On what operating system?

### Please provide any additional information below.

[[!format sh """
# 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

# End of transcript or log.
"""]]

> [[done]] per my comment. (Please comment if you disagree!) --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="108.236.230.124"
 subject="comment 1"
 date="2014-05-16T18:34:49Z"
 content="""
You can get the same effect by running `git annex vicfg` in 2 repositories at the same time, and adding different groups. When the repositories sync and merge, things end up in 2 groups.

So, this is something that git-annex has to deal with being done, even if the configuration does not make sense. It deals with it by treating such a configuration the same as if the repository was in no groups, as far as preferred content is concerned.

So, I don't see much point in adding configuration time checks, since they'd not catch all ways this can happen.
"""]]


code:
### Please describe the problem.

When cloning/syncing a repository (and probably doing some nono's in the process),
git annex will happily delete files.
This cost me several files, which just by coincidence were not totally important, still its *very* unsettling.

### What steps will reproduce the problem?

I did not try to exactly reproduce it yet (sorry, no time right now), but here is vaguley what I did (sorry its been a process spread over
several hours and i was doing lots of other things in parallel so I'm fuzzy about details):

 * have a repository in direct mode on your local harddrive, say ~/myannex
 * git clone ~/myannex to /usbhd/myannex, git annex init.
   The usbhd is a FAT, git annex recognizes it as "crippled filessytem".
 * Git annex get all from ~/myannex. So far, so good.
 * create several files on ~/myannex, git annex add them
 * do a git annex add on them, abort it (realizing SHA256E takes forever, so changing to WORM), repeat add
   (not sure wheter i did a git annex sync here)
 * create several files on /usbhd/myannex, git annex add them
   (not sure wheter i did a git annex sync here again)

All repos are in direct mode.

From here on i don't remember the exact order of events, one definite -- probably important -- nono i did,
was:
I executed a git annex sync/get on the usbhd in a sub-directory (i.e. not in the git base dir), say /usbhd/myannex/foo/bar/,
so it went on creating /usbhd/myannex/foo/bar/foo, which of course was not intended.
However /usbhd/myannex/foo/bar/foo contained FAT-crippled-symlinks to the new files in ~/myannex (good).

In order to avoid a potential messy situation i just renamed /usbhd/myannex/foo to /usbhd/myannex/foo_bak
(which I just realize while writing this, saved me the hash values of my files, yay :))

However when I tried to repeat the procedure, it seems that the new files would not appear on the usbhd (for a reason i totally don't get, maybe I synced back before realizing my sub-foo mistake).
When I synced usbhd -> ~/myannex again, git-annex happily deleted my new files there which obviously quite upset me.

Again, sorry for this horribly chaotic description,
I'll try and deliver a more reproducible description, but for the next 2 weeks at least I'm too busy for that.

### What version of git-annex are you using? On what operating system?

Archlinux,
3.9.2-1-ARCH #1 SMP PREEMPT Sat May 11 20:31:08 CEST 2013 x86_64 GNU/Linux

aur/git-annex-bin 4.20131002-1

### Please provide any additional information below.

[[!format sh """
# 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

# End of transcript or log.
"""]]

[[!tag moreinfo]]


code:
[[!comment format=mdwn
 username="http://droggl.myopenid.com/"
 ip="92.76.150.86"
 subject="comment 1"
 date="2013-10-08T07:46:35Z"
 content="""
Just in case you wonder: the most important (in the sense of not backupped elswhere) files where some scripts which i did hash with SHA256E and not with WORM.
"""]]


code:
[[!comment format=mdwn
 username="http://cstork.org/"
 nickname="Chris Stork"
 subject="git annex get/sync don't delete files"
 date="2013-10-10T11:43:29Z"
 content="""
AFAIU it's impossible for the 'get' subcommand to delete anything because it only copies files to .git/annex/objects.

'sync' should also never delete files because it only adds files to the annex (i.e. checksums them and sets up the links and directories in .git/annex), commits things to git and pulls/pushes the git-annex specific branches to/from other repos.

So I think some other 'nono' must have messed up your files.

If you ever used (maybe unintentionally) used indirect mode there seem to be a rather high chance that some of your otherwise lost content is still in .git/annex/objects.  Did you check if there's are any files in .git/annex/objects ?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="64.134.31.139"
 subject="comment 3"
 date="2013-10-16T20:45:25Z"
 content="""
At least part of this sounds like [[direct_mode_assistant_in_subdir_confusion]]. The report is too confused for me to tell if that's the whole of the problem.

Note that git-annex stores files in git, so if it did something wrong, you can switch to indirect mode, and use regular git commands to check out a tree from before the problem occurred.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.47"
 subject="comment 4"
 date="2013-10-26T19:26:22Z"
 content="""
I have moreinfoed this bug, until I hear back with a better problem description.

Using `git log --stat` to investigate any commits where files were removed would probably be a useful way to get a handle on what happened.
"""]]


code:
### Please describe the problem.

Running git-annex merge shows the output "git-annex merge ", followed by a blinking cursor. The command never seems to end.

### What steps will reproduce the problem?

### What version of git-annex are you using? On what operating system?

4.20130827-gd04d9bb on MacOS X Mountain Lion

### Please provide any additional information below.

dtruss output at https://www.dropbox.com/s/4b3yqn7ajfz5el2/annex-merge.log

[[!meta title="no indication when git-annex is stuck waiting for a lock"]]

[[!tag confirmed]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.153.255.110"
 subject="comment 1"
 date="2013-09-09T15:45:17Z"
 content="""
The relevant part of the log is:

<pre>
65332/0x53591a:  open(\"/Users/gsolsberry/annex/.git/annex/journal.lck\0\", 0x601, 0x1B6)          = 8 0
65332/0x53591a:  fcntl(0x8, 0x9, 0x107009D60)            = -1 Err#-1
</pre>

waitToSetLock thinks fcntl is failing to lock the file due to something else having it locked, and retries, leading to the hang.

I'm told on irc that this was installed using the prebuilt image, and that a previous version of it didn't have the problem.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawl8B4Ima-VCCJ4y32Gvfii8EmvTyN9tFGM"
 nickname="Glendon"
 subject="comment 2"
 date="2013-09-09T15:54:59Z"
 content="""
With latest 20130909 version, the following log from git-annex merge:

https://www.dropbox.com/s/3hklzfsflpxuk5s/annex-merge.log.1
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.153.255.110"
 subject="comment 3"
 date="2013-09-09T19:35:25Z"
 content="""
This problem cleared up after a reboot (and a crash, apparently).

<pre>
joeyh so, my thought is that perhaps you had a git-annex process before that was holding the lock.
joeyh for example, if you ran it and ctrl-z'd at just the right time, it could be suspended and holding the lock
joeyh (or the kernel coud have gotten confused, which given you also had a crash, who knows..)
dp sounds logical
joeyh forcing locks is always a problimatic thing
joeyh but git-annex could certainly notice if it seems to be stalled and print some useful messages
joeyh and maybe have a way to run with locks forced
</pre>
"""]]


code:
[[!meta title="network-muticast FD leak fix not deployed to Linux autobuilds yet"]]

### Please describe the problem.
After running git-annex some minutes, the websites is not responsible any more and it even crashes eventually.

### What steps will reproduce the problem?
Start the assistant.

### What version of git-annex are you using? On what operating system?
it-annex version: 4.20130802-g1452ac3
build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP

### Please provide any additional information below.

[[!format sh """
# 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
[2013-08-06 13:32:51 CEST] main: starting assistant version 4.20130802-g1452ac3

Already up-to-date.
(scanning...) [2013-08-06 13:32:51 CEST] Watcher: Performing startup scan

Already up-to-date.
(started...)
git-annex: accept: resource exhausted (Too many open files)
[2013-08-06 19:50:37 CEST] read: git ["--git-dir=/home/christian/git-annex/.git","--work-tree=/home/+christian/git-annex","symbolic-ref","HEAD"]
git-annex: runInteractiveProcess: pipe: Too many open files
[2013-08-06 19ND:ea5te1Wm:ao1tn1cS htCeaErtSFuTas]l  lcNbreaatcsWkha etcdcr:ha es/rhh:eo dmd:ee /tgc+eihctrt:ie sdct rineaeantt/wegoPirrtko- cacenosnnsen:xe /cr.tegisiootnu/
racnen[ e2ex0x/1h:3a -uo0sp8te-en0dT6 e (m1Tp9oF:oi5 l1me:a:1n 1yr  eCosEpoSeuTnr] c feri eleaexdsh:+)a
ugsitte d[ "(-T-ogoi tm-adniyr =o/pheonm ef/iclhersi)s
tian/git-annex/.git","--work-tree=/home/christian/git-annex","symbolic-ref","HEAD"]
git-annex: runInteractiveProcess: pipe: Too many open files
git-annex: git: createProcess: resource exhausted (Too many open files)
[2013-08-06 19:51:11 CEST] NetWatcherFallback: warning NetWatcherFallback crashed: git: createProces+s: resource exhausted (Too many open files)
[2013-08-06 19:51:11 CEST] DaemonStatus: warning DaemonStatus crashed: /home/christian/git-annex/.gi+t/annex/: openTempFile: resource exhausted (Too many open files)

(system was asleep from 14:00 until 19:50)

# End of transcript or log.
"""]]

> [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="chrisbra"
 ip="80.149.220.45"
 subject="sorry, added some wrapping signs from vim."
 date="2013-08-06T18:01:40Z"
 content="""
[2013-08-06 13:32:51 CEST] main: starting assistant version 4.20130802-g1452ac3

Already up-to-date.
(scanning...) [2013-08-06 13:32:51 CEST] Watcher: Performing startup scan

Already up-to-date.
(started...)
git-annex: accept: resource exhausted (Too many open files)
[2013-08-06 19:50:37 CEST] read: git [\"--git-dir=/home/christian/git-annex/.git\",\"--work-tree=/home/christian/git-annex\",\"symbolic-ref\",\"HEAD\"]
git-annex: runInteractiveProcess: pipe: Too many open files
[2013-08-06 19ND:ea5te1Wm:ao1tn1cS htCeaErtSFuTas]l  lcNbreaatcsWkha etcdcr:ha es/rhh:eo dmd:ee /tgceihctrt:ie sdct rineaeantt/wegoPirrtko- cacenosnnsen:xe /cr.tegisiootnu/
racnen[ e2ex0x/1h:3a -uo0sp8te-en0dT6 e (m1Tp9oF:oi5 l1me:a:1n 1yr  eCosEpoSeuTnr] c feri eleaexdsh:)a
ugsitte d[ \"(-T-ogoi tm-adniyr =o/pheonm ef/iclhersi)s
tian/git-annex/.git\",\"--work-tree=/home/christian/git-annex\",\"symbolic-ref\",\"HEAD\"]
git-annex: runInteractiveProcess: pipe: Too many open files
git-annex: git: createProcess: resource exhausted (Too many open files)
[2013-08-06 19:51:11 CEST] NetWatcherFallback: warning NetWatcherFallback crashed: git: createProcess: resource exhausted (Too many open files)
[2013-08-06 19:51:11 CEST] DaemonStatus: warning DaemonStatus crashed: /home/christian/git-annex/.git/annex/: openTempFile: resource exhausted (Too many open files)

"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="2001:4978:f:21a::2"
 subject="comment 2"
 date="2013-08-07T15:59:59Z"
 content="""
What operating system is this?

Can you see which files the git-annex process has open?
"""]]


code:
[[!comment format=mdwn
 username="chrisbra"
 ip="212.121.153.12"
 subject="This is ubuntu 12.10"
 date="2013-08-12T13:30:00Z"
 content="""
This is ubuntu 12.10 and seems to be the same problem which has been mentioned before (resource exhausted or similar)
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawlmRpGORNKWimtzqItvwm4I6cn16vx8OvU"
 nickname="hayden"
 subject="Many network sockets with associated fds hanging around"
 date="2013-08-15T18:00:42Z"
 content="""
I see something similar in logs and after roughly 10 mins the web-apps dies.
So I think I hit the same as the above user.
Sometimes I get thread deaths and restart requests but the root cause appears to match the scenario mentioned over.
Often the webapp just hangs.  But always when it hits the fd ulimit... 1024 on this system.

git-annex version is 4.20130802-g1452ac3 and I used the static-linked linux tar.gz linux-binary download.

Test setup is a from scratch assistant startup on Ubuntu 12.04.
Not exactly a clean ubuntu though, so maybe difficult to duplicate troubles at your end.

I fired up the web-app with a cleaned out config.  No signs of leaks until an annex is created.
On creation of an empty annex I get fd leaks a about 1 per second after a repository is created.
Strace'ing the main process only shows 8-bytes writes (see below) at the same rate as the leak.
Sometimes the fd-leak stops before the resource limit, sometimes not.
Creating a new annex on top of an existing directory tree with many files is pretty reliable trigger though.
Startup scan finishes and fds leak away until the ulimit is hit.

    hayden@orca:~/gamma$ ls /proc/26319/fd
    0  10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  38  4   41  43  45  6  8
    1  11  13  15  17  19  20  22  24  26  28  3   31  33  35  37  39  40  42  44  5   7  9
    hayden@orca:~/gamma$ ls /proc/26319/fd
    0  10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  38  4   41  43  45  6  8
    1  11  13  15  17  19  20  22  24  26  28  3   31  33  35  37  39  40  42  44  5   7  9
    hayden@orca:~/gamma$ ls /proc/26319/fd
    0  10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  38  4   41  43  45  5  7  9
    1  11  13  15  17  19  20  22  24  26  28  3   31  33  35  37  39  40  42  44  46  6  8

    hayden@orca:~/gamma$ ls /proc/26319/fd/43
    /proc/26319/fd/43

    hayden@orca:~/gamma$ ls -l  /proc/26319/fd/43
    ls -l  /proc/26319/fd/43
    lrwx------ 1 hayden hayden 64 Aug 14 21:10 /proc/26319/fd/43 -> socket:[568994]

    hayden@orca:~/gamma$ lsof | grep 568994
    git-annex 26319     hayden   43u     IPv4             568994      0t0      UDP 224.0.0.251:55556

    hayden@orca:~/gamma$ uname -a
    Linux orca 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

    hayden@orca:~/gamma$ cat /etc/issue
    Ubuntu 12.04 LTS \n \l

    hayden@orca:~/gamma$ fuser 55556/udp -a
    55556/udp:            4415 26319 27080 27083

    hayden@orca:~/gamma$ ps aux | grep 4415
    hayden    4415  0.0  0.0  66716  3036 ?        S    Aug12   0:03 curl -s --head -L http://127.0.0.1:38464/?auth=da9c4aba4cc2db9cf78574753f6e94d8031c6a7bdf8bfe100bde868f57b81fd751965cc9d68a9afac79f826d257a256a04ce62615a7f23cd7c925969dda1c7b8 -w %{http_code}
    hayden   27458  0.0  0.0  10612   924 pts/0    S+   21:50   0:00 grep --color=auto 4415

    hayden@orca:~/gamma$ ps aux | grep 26319
    hayden   26319  0.1  0.7 497188 28560 pts/5    Sl   21:09   0:04 git-annex webapp
    hayden   26338  3.4  3.4 1035572 137864 pts/5  Sl   21:09   1:25 /usr/lib/firefox/firefox /tmp/webapp26319.html
    hayden   27460  0.0  0.0  10612   920 pts/0    S+   21:50   0:00 grep --color=auto 26319

    hayden@orca:~/gamma$ ps aux | grep 27080
    hayden   27080  0.0  0.0  16476  1288 pts/5    S    21:33   0:00 git --git-dir=/home/hayden/boo/.git --work-tree=/home/hayden/boo cat-file --batch
    hayden   27462  0.0  0.0  10612   924 pts/0    S+   21:50   0:00 grep --color=auto 27080

    hayden@orca:~/gamma$ ps aux | grep 27083
    hayden   27083  0.0  0.0  16476  1060 pts/5    S    21:33   0:00 git --git-dir=/home/hayden/boo/.git --work-tree=/home/hayden/boo check-attr -z --stdin annex.backend annex.numcopies --
    hayden   27464  0.0  0.0  10612   920 pts/0    S+   21:51   0:00 grep --color=auto 27083

----> has 579 open fds at this point but this number holds stable over 10 min
(copy in new tree to provoke)
(no change)
----> restart daemon in gui to provoke
(new process has open fds slowly climbing after startup scan)

straces look like this repeating every second. (clipped down)

    futex(0x34f001c, FUTEX_WAIT_PRIVATE, 51, NULL) = ? ERESTARTSYS (To be restarted)
    --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
    rt_sigreturn(0x1a)                      = 202
    futex(0x34f001c, FUTEX_WAIT_PRIVATE, 51, NULL) = ? ERESTARTSYS (To be restarted)
    --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
    rt_sigreturn(0x1a)                      = 202
    futex(0x34f001c, FUTEX_WAIT_PRIVATE, 51, NULL) = ? ERESTARTSYS (To be restarted)
    --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
    rt_sigreturn(0x1a)                      = 202
    futex(0x34f001c, FUTEX_WAIT_PRIVATE, 51, NULL) = ? ERESTARTSYS (To be restarted)
    --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
    write(6, \"\377\0\0\0\0\0\0\0\", 8)       = 8
    rt_sigreturn(0x2)                       = 202
    futex(0x34f001c, FUTEX_WAIT_PRIVATE, 51, NULL^C <unfinished ...>
    Process 29803 detached

Until after roughly 10 mins...

    hayden@orca:~/boo$ ls /proc/29803/fd | wc -l
    1017
    hayden@orca:~/boo$ ls /proc/29803/fd | wc -l
    1023
    hayden@orca:~/boo$ ls /proc/29803/fd | wc -l
    1024
    hayden@orca:~/boo$ ls /proc/29803/fd | wc -l
    1024
    hayden@orca:~/boo$ ls /proc/29803/fd | wc -l
    1024
    hayden@orca:~/boo$ ls /proc/29803/fd | wc -l
    1024

    hayden@orca:~/boo$ ulimit -a
    core file size          (blocks, -c) 0
    data seg size           (kbytes, -d) unlimited
    scheduling priority             (-e) 0
    file size               (blocks, -f) unlimited
    pending signals                 (-i) 31164
    max locked memory       (kbytes, -l) 64
    max memory size         (kbytes, -m) unlimited
    open files                      (-n) 1024
    pipe size            (512 bytes, -p) 8
    POSIX message queues     (bytes, -q) 819200
    real-time priority              (-r) 0
    stack size              (kbytes, -s) 8192
    cpu time               (seconds, -t) unlimited
    max user processes              (-u) 31164
    virtual memory          (kbytes, -v) unlimited
    file locks                      (-x) unlimited
    hayden@orca:~/boo$

At this point the webapp hangs but a number of interesting crashes may occur. I've also seen the particular error in the previous users log (on a big tree).

    [2013-08-14 21:56:12 CEST] main: starting assistant version 4.20130802-g1452ac3
    (scanning...) [2013-08-14 21:56:12 CEST] Watcher: Performing startup scan
    (started...) DaemonStatus crashed: /home/hayden/boo/.git/annex/: openTempFile: resource exhausted (Too many open files)
    [2013-08-14 22:06:12 CEST] DaemonStatus: warning DaemonStatus crashed: /home/hayden/boo/.git/annex/: openTempFile: resource exhausted (Too many open files)

Is any of the above helpful?  Anything else useful to kick for testing that you'd like done?
I'd guess this is something weird with my ubuntu setup that provokes this as more users would see it otherwise.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.63"
 subject="comment 5"
 date="2013-08-24T17:09:43Z"
 content="""
Thanks for an excellent amount of debug information.

I can see what's leaking is UDP connections to 224.0.0.251. That address is used for the \"local pairing\" option in the webapp.

I was able to reproduce the problem by disabling all network interfaces except `lo`. The PairListener then failed to open a multicast listening socket. When it fails that way, it retried every second, as you noticed. And there is a socket leak in that failure mode.

I wonder if you're seeing this even when on the network? If so, perhaps your Ubuntu system has something going on that prevents opening a multicast listening socket on even `eth0` or `wlan0` or whatever.

Unfortunately, the actual socket leak bug is in the [network-multicast](http://hackage.haskell.org/package/network-multicast) library, and not in git-annex.  I have filed an upstream bug report: <https://github.com/audreyt/network-multicast/issues/4>

Hopefully that will be dealt with soon. There is a workaround I could do in git-annex: If it fails (leaking one socket), it could wait until the NetworkListener indicated a new network interface was opened, before trying again (possibly leaking one socket again). This would change it from a 1 per second leak to a 1 per change of network leak at worst, which is probably much less likely to cause problems.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.63"
 subject="comment 6"
 date="2013-08-24T18:38:56Z"
 content="""
My NetListener workaround turned out to not be portable enough.

However, I have sent a patch to fix the FD leak: <https://github.com/audreyt/network-multicast/pull/6>
Hopefully it gets applied soon.

I have also made the PairListener only retry every 60 seconds. Which makes the leak 1/60th as bad, for whatever that's worth.

Once a fix for this gets into Debian, I need to remember to backport it to stable, and update the autobuilders to use it. Also need to remember to update the Android autobuilder. Leaving this bug report open until that happens.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.227"
 subject="comment 7"
 date="2014-01-01T17:29:03Z"
 content="""
OSX, Android, Windows all updated. Debian backport and linux autobuilds updated.
"""]]


code:
### Please describe the problem.

git-annex is back on the radar now that the jabber requirement has been dropped! :-)

But, it seems as though when I create a remote repo via the webapp it always makes it a bare git repo.  Even when I specify the "client usage grouping".

If I manually create two repos on ssh enabled servers, manually link them, and fire up the assistant they are awesomely kept in sync (with no bare repo in sight).

### What steps will reproduce the problem?

Use the webapp to try to create a client usage remote repo.

### What version of git-annex are you using? On what operating system?

Latest as of post.

### Please provide any additional information below.

[[!format sh """
# 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

# End of transcript or log.
"""]]

> [[notabug|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.114"
 subject="comment 1"
 date="2014-04-24T18:00:52Z"
 content="""
Please use descriptive bug titles.

The webapp configures some common use cases, not every possible use case. Running git-annex assistant on a remote server to keep a directory there updated is not a relatively common use case. You can do it if you want; and if someone provided a very complelling UI markup that made sense to regular users it might be added to the webap (but this seems unlikely.

As it is, the webapp set up bare git repositories on remotes, because that is by far the most common useful way to use git on a remote server. And if the webapp's local pairing interface is used, two existing non-bare client repositories will be paired, and the new remotedaemon will help keep the in sync.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
 nickname="Matt"
 subject="comment 2"
 date="2014-04-24T18:43:50Z"
 content="""
hmmm - I think that it's arguable that if in the repository group drop down I select \"client\" then the remote repo should *not* be bare.

I would predict that this new functionality will supercede the existing use-cases in terms of popularity.  It's very cool that all my machines can be kept in sync with just ssh - a walkthrough showing desktop, laptop, and phone all just syncing (i.e., without the cloud transfer repo and jabber complications) makes a much simpler and compelling advert for this cool code!  But it won't happen unless the GUI supports it...
"""]]