code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.252.11.120"
 subject="comment 3"
 date="2012-11-13T17:11:51Z"
 content="""
This has been previously reported: [[bugs/OSX_git-annex.app_error:__LSOpenURLsWithRole()]]

No clue what that error is supposed to mean.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
 nickname="Jimmy"
 subject="comment 4"
 date="2012-11-16T13:02:40Z"
 content="""
sadly i only have a 10.7 machine to create the builds, so I have no experience with 10.8. I haven't had a 10.6 machine in a while to create the builds. Anyone else want to work together in setting up another 10.6 or 10.8 builder for others?
"""]]

repo_name: kakafarm/git

license: unknown


code:
So you have two computers that are not in the same place, and you want them
to share the same synchronised folder, communicating directly with each other.

[[!inline feeds=no template=bare pages=videos/git-annex_assistant_remote_sharing]]

You can add even more computers using the same method shown here.

----

If you have a laptop that is sometimes near another computer, you can
speed up file transfers when it is by also connecting it using the
[[local_pairing_walkthrough]].


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmG4rlD9k1ezNkYZ8jDbITrycUmHV-P8Qs"
 nickname="Jeroen"
 subject="Synced vs. unsynced"
 date="2013-07-29T18:07:45Z"
 content="""
I've noticed that it is also possible to add an existing annex folder on a remote server without using syncing. Are there any dangers in doing this?

Could you explain what syncing does and when it is needed? Thanks.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="4.154.0.21"
 subject="comment 2"
 date="2013-07-30T18:08:38Z"
 content="""
I'm afraid I don't quite understand the question.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 4"
 date="2013-11-12T18:18:16Z"
 content="""
You can easily use a removable drive as a transfer repository to sync two computers that have no network connection. Just use the webapp to add the drive on one computer. The drive will be set up as a transfer repository by default. The webapp will automatically start copying all your files to it. Then you can disconnect the drive, bring it to the other computer, and repeat the process. Everything from the first computer will then sync over from the drive to the second computer. And repeat moving the drive back and forth to keep things in sync.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmkXtBdMgE1d9nCz2iBc4f85xh4izZ_auU"
 nickname="Ulrich"
 subject="Using a portable drive as another transfer device?"
 date="2013-11-12T16:52:12Z"
 content="""
I try to understand how to setup git-annex for the following use case:

Two computers, that are paired via remote sharing, using some cloud repository for transfer, and a local NAS for backups.

These two computers are sometimes in the same network, sometimes in different networks, and sometimes even without network at all. From what I read, it should be possible to bypass the cloud when these two machines are on the same network, which sounds great.

Would it be possible to use a portable drive as \"another link\" between these two computers that can be used to sync them even if there is no network between them?

And as you write, if the pairing has been set up manually, then everything is fine - so could it be that it is really easy and only necessary to setup the git-annex on the local drive as an additional remote on both (or only one?) machine?

thanks for any insight!
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmkXtBdMgE1d9nCz2iBc4f85xh4izZ_auU"
 nickname="Ulrich"
 subject="Using a portable drive as another transfer device? – cool."
 date="2013-11-14T19:05:56Z"
 content="""
Thanks - I was hoping that it is that easy. I'll try that as soon as I have a working version of the latest git-annex (trying to build with brew for Mac OS X 10.9, but without success so far).
"""]]


code:
[[!comment format=mdwn
 username="severo"
 ip="88.182.182.135"
 subject="git-assistant and transfer repository"
 date="2014-03-16T17:05:43Z"
 content="""
In your comment http://git-annex.branchable.com/assistant/remote_sharing_walkthrough/#comment-f97efe1d05c0101232684b4e4edc4866, you describe a way to synchronize two devices using an intermediate USB drive configured as a \"transfer repository\".

I understand that in that case, the USB drive can only be used as a \"transmitter\", in a git repository form, not as a copy of the files structure. This means the files contained by the USB drive cannot be accessed without git/git-annnex.

Is there a way to use the USB drive as a \"client repository\" in order to allow synchronization, as described earlier, but also as a simple copy of the files, in order to access them from any device (opening them with windows in a cyber coffee for example).

Thanks
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.154"
 subject="comment 7"
 date="2014-03-17T19:50:48Z"
 content="""
@severo the web app does not support setting up that use case. However, you can make a non-bare clone of your repository onto a removable drive, and if you do the assistant will use it just the same as if you'd set up a removable drive using the webapp. Note that you will need to run `git annex sync` inside that repository in order to update the tree it displays.
"""]]


code:
[[!comment format=mdwn
 username="severo"
 ip="95.152.107.168"
 subject="comment 8"
 date="2014-03-18T10:06:50Z"
 content="""
Thansk @joeyh.name for your answer. Do you think this feature could be integrated into the git-annex assistant ?
"""]]


code:
[[!comment format=mdwn
 username="severo"
 ip="95.152.107.168"
 subject="comment 9"
 date="2014-03-18T11:16:19Z"
 content="""
Some explanations in French on how to do: http://seenthis.net/messages/237648#message238202
"""]]


code:
Want to share all the files in your repository with a friend?

Let's suppose you use Google Mail, and so does your friend, and you
sometimes also chat in Google Talk. The git-annex assistant will
use your Google account to share with your friend. (This actually
works with any Jabber account you use, not just Google Talk.)

Start by opening up your git annex dashboard.

[[!img local_pairing_walkthrough/addrepository.png alt="Add another repository button"]]

`*click*`

[[!img pairing.png alt="Share with a friend"]]

`*click*`

[[!img xmpp.png alt="Configuring Jabber account"]]

Fill that out, and git-annex will be able to show you a list of your
friends.

[[!img buddylist.png alt="Buddy list"]]

This list will refresh as friends log on and off, so you can
leave it open in a tab until a friend is available to start pairing.

(If your friend is not using git-annex yet, now's a great time to spread
the word!)

Once you click on "Start Pairing", your friend will see this pop up
on their git annex dashboard.

[[!img xmppalert.png alt="Pair request"]]

Once your friend clicks on that, your repositories will be paired.

### But, wait, there's one more step...

Despite the repositories being paired now, you and your friend can't yet
quite share files. You'll start to see your friend's files show up in your
git-annex folder, but you won't be able to open them yet.

What you need to do now is set up a repository out there in the cloud,
that both you and your friend can access. This will be used to transfer
files between the two of you.

At the end of the pairing process, a number of cloud providers are
suggested, and the git-annex assistant makes it easy to configure one of
them. Once you or your friend sets it up, it'll show up in the other
one's list of repositories:

[[!img repolist.png alt="Repository list"]]

The final step is to share the login information for the cloud repository
with your friend, so they can enable it too.

With that complete, you'll be able to open your friend's files!


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawl6RDLuI2b2fHkTRseVQGUNjcQ2qUrOaE0"
 nickname="Фёдор"
 subject="comment 1"
 date="2014-05-25T15:10:34Z"
 content="""
Do we need a cloud repository just to bypass NAT? I understand it can't share files within Jabber, but it just looks unpolished. Maybe some punching techniques might be handy, pwnat for example.
"""]]


code: [[!meta redir="/thanks#kickstarter"]]


code:
Running `git annex sync` or using the [[assistant]] involves merging
changes from elsewhere into your repository's currently checked out branch.
This could lead to a merge conflict, perhaps because the same file
got changed in two different ways. A nice feature is that these
merge conflicts are automatically resolved, rather than leaving
git in the middle of a conflicted merge, which would prevent further
syncing from happening.

When a conflict occurs, there will be several messages printed about the merge
conflict, and the file that has the merge conflict will be renamed, with
".variant-XXX" tacked onto it. So if there are two versions of file foo,
you might end up with "foo.variant-AAA" and "foo.variant-BBB". It's then
up to you to decide what to do with these two files. Perhaps you can
manually combine them back into a single file. Or perhaps you choose to
rename them to better names and keep two versions, or delete one version
you don't want.

The "AAA" and "BBB" in the above example are essentially arbitrary
(technically they are the MD5 checksum of the key). The automatic merge
conflict resoltuion is designed so that if two or more repositories both get
a merge conflict, and resolve it, the resolved repositories will not
themselves conflict. This is why it doesn't use something nicer, like
perhaps the name of the remote that the file came from.


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnJTqmRu1YCKS2Hsm4vtOflLhP4fU-k98w"
 nickname="Ahmed"
 subject="Customise conflict resolution behaviour"
 date="2014-02-25T11:42:08Z"
 content="""
How to customise git-annex conflict resolution behaviour, such that for example: change naming convention of conflicted files with suffix or prefix, move conflicted files to another directory structure, overwrite conflicted files from preferred content ...

"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
 nickname="Matthias"
 subject="Use automatic merge without syncing"
 date="2014-03-20T10:03:41Z"
 content="""
Is there a possibility to use the automatic merge logic without using \"git annex sync\"? I don't want to have the \"synced\"-branches, but the auto-conflict-resolution is very nice.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.102"
 subject="comment 3"
 date="2014-03-20T16:10:10Z"
 content="""
@Matthias `git annex merge` will do what you want, as long as you have git-annex 4.20130709 or newer.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
 nickname="Matthias"
 subject="merge for master branch?"
 date="2014-03-23T23:02:23Z"
 content="""
As far as I observed, \"git annex merge\" only merges the \"git-annex\" branch. My wish is to have the conflict resolution from \"git annex sync\" in the \"master\" branch, but no automatic commit, such that the user can verify and possibly correct the merge. The proposed merge could go to the index. Consider the following scenario:

1. We have repo A, B, and CENTRAL
2. All three start with a root commit in \"master\" branch
3. Then A commits a file \"test.txt\" with content \"a\" and syncs with CENTRAL
4. Meanwhile, B commits \"test.txt\" with content \"b\"
5. When B tries to sync with CENTRAL, the proposed conflict resolution having two files \"test.txt-variantXXXX\" and \"test.txt-variantYYYY\" should be staged in the index, but not committed yet.
6. B can now commit a custom merge, e.g. with file content \"ab\".

The point is that I really like the conflict resolution, but still want to force the user to check the result.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.41"
 subject="comment 5"
 date="2014-03-26T18:56:30Z"
 content="""
@Matthias you need to install git-annex 4.20130709 or newer. Then `git-annex merge` will do what you want. As I said before.

As for committing the merge, you can always adjust the result after the fact and use `git commit --amend`.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
 nickname="Matthias"
 subject="auto conflict resolution master branch"
 date="2014-04-13T17:48:19Z"
 content="""
@joeyh: This must be a misunderstanding of what I want. I use version 5.20140320. I can't find a workflow where \"git annex merge\" changes my master branch, it only updates the git-annex branch.

Thinking again of it after some time, I am basically fine with \"git annex sync\". The only thing I am uncomfortable with is that the automatic merge is pushed without review.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.191"
 subject="comment 7"
 date="2014-04-17T20:00:22Z"
 content="""
@Matthias, here is an example of git-annex merge updating the master branch from the synced/master branch that was pushed to it earlier:

<pre>
joey@darkstar:~/tmp/test/2>git annex merge
merge git-annex (merging synced/git-annex into git-annex...)
ok
merge synced/master
Updating 7942eee..1f3422e
Fast-forward
 new_file | 1 +
 1 file changed, 1 insertion(+)
 create mode 120000 new_file
ok
</pre>

If you are having trouble with it somehow, I'd suggest filing a bug report.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
 nickname="Matthias"
 subject="auto conflict resolution"
 date="2014-04-19T17:26:11Z"
 content="""
Thanks Joey, I could construct a scenario where the auto-conflict-resolution was applied in the master branch.
"""]]


code:
When a file is annexed, a key is generated from its content and/or metadata.
The file checked into git symlinks to the key. This key can later be used
to retrieve the file's content (its value).

Multiple pluggable key-value backends are supported, and a single repository
can use different ones for different files.

* `SHA256E` -- The default backend for new files, combines a 256 bit SHA-2
  hash of the file's content with the file's extension. This allows
  verifying that the file content is right, and can avoid duplicates of
  files with the same content. Its need to generate checksums
  can make it slower for large files.
* `SHA256` -- Does not include the file extension in the key, which can
  lead to better deduplication but can confuse some programs.
* `WORM` ("Write Once, Read Many") This assumes that any file with
  the same basename, size, and modification time has the same content.
  This is the least expensive backend, recommended for really large
  files or slow systems.
* `SHA512`, `SHA512E` -- Best SHA-2 hash, for the very paranoid.
* `SHA1`, `SHA1E` -- Smaller hash than `SHA256` for those who want a checksum
   but are not concerned about security.
* `SHA384`, `SHA384E`, `SHA224`, `SHA224E` -- Hashes for people who like
  unusual sizes.
* `SKEIN512`, `SKEIN512E`, `SKEIN256`, `SKEIN256E`
  -- [Skein hash](http://en.wikipedia.org/wiki/Skein_hash),
  a well-regarded SHA3 hash competition finalist.

The `annex.backends` git-config setting can be used to list the backends
git-annex should use. The first one listed will be used by default when
new files are added.

For finer control of what backend is used when adding different types of
files, the `.gitattributes` file can be used. The `annex.backend`
attribute can be set to the name of the backend to use for matching files.

For example, to use the SHA256E backend for sound files, which tend to be
smallish and might be modified or copied over time,
while using the WORM backend for everything else, you could set
in `.gitattributes`:

	* annex.backend=WORM
	*.mp3 annex.backend=SHA256E
	*.ogg annex.backend=SHA256E


code:
[[!comment format=mdwn
 username="http://nanotech.nanotechcorp.net/"
 nickname="NanoTech"
 subject="SHA performance"
 date="2012-08-10T04:37:32Z"
 content="""
It turns out that (at least on x86-64 machines) `SHA512` [is faster than][1] `SHA256`. In some benchmarks I performed1 `SHA256` was 1.8–2.2x slower than `SHA1` while `SHA512` was only 1.5–1.6x slower.

`SHA224` and `SHA384` are effectively just truncated versions of `SHA256` and `SHA512` so their performance characteristics are identical.

[1]: https://community.emc.com/community/edn/rsashare/blog/2010/11/01/sha-2-algorithms-when-sha-512-is-more-secure-and-faster
1 `time head -c 100000000 /dev/zero | shasum -a 512`
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
 nickname="Stéphane"
 subject="Tracking remote copies not even stored locally / URL backend turned into a "special remote"."
 date="2013-01-03T10:59:35Z"
 content="""
In case you came here looking for the URL backend.

## The URL backend

Several documents on the web refer to a special \"URL backend\", e.g. [Large file management with git-annex [LWN.net]](http://lwn.net/Articles/419241/).  Historical content will never be updated yet it drives people to living places.

## Why a URL backend ?

It is interesting because you can:

* let `git-annex` rest on the fact that some documents are available as extra copies available at any time (but from something that is not a git repository).
* track these documents like your own with all git features, which opens up some truly marvelous combinations, which this margin is too narrow to contain (Pierre d.F. wouldn't disapprove ;-).

## How/Where now ?

`git-annex` used to have a URL backend. It seems that the design changed into a \"special remote\" feature, not limited to the web. You can now track files available through plain directories, rsync, webdav, some cloud storage, etc, even clay tablets. For details see [[special remotes]].

"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE"
 nickname="Thomas"
 subject="Please be more specific about what information goes into the key"
 date="2013-07-31T11:55:09Z"
 content="""
It's a bit confusing to read that SHA256 does not include the file extension from which I can deduct that SHA256E does include it. What else does it include? I used to \"seed\" my git-annex with localy available data by \"git-annex add\"-ing it in a temporary folder without doing a commit and than to initiate a copy from the slow remote annex repo. My theory was that remote copy sees the pre-seeded files and does not need to copy them again.

But does this theory hold true for different file names, extensions, modification date, full path? Maybe you could also link to the code that implements the different backends so that curious readers can check for themselves.

Thank you!
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmTho3mActvetF1iQdmui6gH1t6WE6c284"
 nickname="Michael"
 subject="SHA256e"
 date="2013-10-30T02:00:45Z"
 content="""
I'd really like to have a SHA256e backend -- same as SHA256E but making sure that extensions of the files in .git/annex are converted to lower case.  I normally try to convert filenames from cameras etc to lower case, but not all people that I share annex with do so consistently.
In my use case, I need to be able to find duplicates among files and .jpg vs .JPG throws git annex dedup off.  Otherwise E backends are superior to non-E for me.  Thanks, Michael.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM"
 nickname="Jarno"
 subject="Non-E backend drawbacks?"
 date="2013-10-30T21:25:00Z"
 content="""
The page states \"[non-E backends] can confuse some programs\". I like the ideal simplicity and recoverability of pure checksum backends but \"confusion\" sounds a bit worrying. Any practical examples of these problems to help me choose?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.47"
 subject="comment 6"
 date="2013-11-01T15:47:26Z"
 content="""
Some examples of problems with the raw SHA backends include, IIRC, calibre, and many programs on OSX. These programs look at the extension of the filename the symlink points at.
"""]]


code:
Due to popular demand, git-annex can now be used with bare repositories.

So, for example, you can stash a file away in the origin:
`git annex move mybigfile --to origin`

Of course, for that to work, the bare repository has to be on a system with
[[git-annex-shell]] installed. If "origin" is on GitWeb, you still can't
use git-annex to store stuff there.

It took a while, but bare repositories are now supported exactly as well
as non-bare repositories. Except for these caveats:

* `git annex fsck` works in a bare repository, but does not display
  warnings about insufficient
  [[copies]]. To get those warnings, just run it in one of the non-bare
  checkouts.
* `git annex unused` in a bare repository only knows about keys used in
  branches that have been pushed to the bare repository. So use it with care..
* Commands that need a work tree, like `git annex add` won't work in a bare
  repository, of course.
* However, you can (with recent versions of git-annex) run `git annex copy`,
  `git annex get`, and `git annex move` in a bare repository. These behave
  as if the `--all` option were used, and just operate on every single
  version of every single file that is present in the git repository
  history.

***

Here is a quick example of how to set this up, using `origin` as the remote name, and assuming `~/annex` contains an annex:

On the server:

    git init --bare bare-annex.git
    cd bare-annex.git && git annex init origin

Now configure the remote and do the initial push:

    cd ~/annex
    git remote add origin example.com:bare-annex.git
    git push origin master git-annex

Now `git annex info` should show the configured bare remote. If it does not, you may have to pull from the remote first (older versions of `git-annex`)

If you wish to configure git such that you can push/pull without arguments, set the upstream branch:

    git branch master --set-upstream origin/master


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmraN_ldJplGunVGmnjjLN6jL9s9TrVMGE"
 nickname="Ævar Arnfjörð"
 subject="How to convert bare repositories to non-bare"
 date="2012-11-11T20:14:44Z"
 content="""
I made a repository bare and later wanted to convert it, this would have worked with just plain git:

    cd bare-repo.git
    mkdir .git
    mv .??* * .git/
    git config --unset core.bare
    git reset --hard

But because git-annex uses different hashing directories under bare repositories all the files in the repo will point to files you don't have. Here's how you can fix that up assuming you're using a backend that assigns unique hashes based on file content (e.g. the SHA256 backend):

    mv .git/annex/objects from-bare-repo
    git annex add from-bare-repo
    git rm -f from-bare-repo

"""]]


code:
This is git-annex's bug list. Closed bugs are moved to [[done]].

[[!inline pages="./bugs/* and !./bugs/*/* and !./bugs/done and !link(done)
and !./bugs/moreinfo and !./bugs/confirmed and !./bugs/forwarded and !*/Discussion"
actions=yes postform=yes show=0 archive=yes template=buglist]]

[[!edittemplate template=templates/bugtemplate match="bugs/*" silent=yes]]


code:
### Please describe the problem.

Some time in may 2014, git-annex stopped working with previous versions of git-annex.

### What steps will reproduce the problem?

Trying to sync with the server fails with:

    git-annex-shell: Not a git-annex or gcrypt repository.

With older versions (e.g. 5.20140412), it's even worse:

    Remote marcos does not have git-annex installed; setting annex-ignore
    This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git config remote.marcos.annex-ignore false

Basically, if git-annex-shell is missing, newer versions of git-annex just crash and burn instead of going the more gentle, backward-compatible way...

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

git-annex from debian sid (5.20140517) on the "client" side and from jessie (5.20140421) on the "server".

### 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
ssh server
git init books
exit
git remote add server server:books
git annex sync server
# End of transcript or log.
"""]]

If this is intended behavior, it seems to me the major version of git annex should be bumped, at the very least... -- [[anarcat]]

[[!tag moreinfo]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="24.159.78.125"
 subject="comment 1"
 date="2014-05-23T14:25:04Z"
 content="""
git-annex has always required the remote have git-annex-shell installed in order to store files on it. Nothing has changed in this area.

So, you seem to be very confused about something, but I cannot tell what from this bug report, and I certianly see no evidence of any bug  in the information provided so far. You need to install git-annex on your server and then it should work, assuming the server actually has a git-annex repository set up on it.
"""]]


code:
[[!comment format=mdwn
 username="https://id.koumbit.net/anarcat"
 ip="72.0.72.144"
 subject="comment 2"
 date="2014-05-27T03:00:48Z"
 content="""
marcos has had git-annex installed ever since i started using git-annex, which is around version 4.x. furthermore, i have assumed that the procedure i detailed in the last part were enough to reproduce the bug, but i may be mistaken.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.176"
 subject="comment 3"
 date="2014-05-27T17:54:06Z"
 content="""
Well, your transcript shows you init a git repository. But you have not run `git annex init` in it, so git-annex-shell won't use it.

"""]]


code:
[[!comment format=mdwn
 username="https://id.koumbit.net/anarcat"
 ip="72.0.72.144"
 subject="comment 4"
 date="2014-06-04T04:53:36Z"
 content="""
ah. i see. certainly an operator error then. feels like a usability issue now, or i just feel stupid, not sure which. :)
"""]]


code:
What steps will reproduce the problem?

Example below illustrates downloading a podcast with git annex addurl:

list directory before...

~/Podcasts/TuxRadar Linux Podcast (Ogg)$ ls
folder.jpg           tuxradar_s04e24.ogg
tuxradar_s04e09.ogg  tuxradar_s05e01.ogg
tuxradar_s04e11.ogg  tuxradar_s05e02.ogg
tuxradar_s04e13.ogg  tuxradar_s05e03.ogg
tuxradar_s04e15.ogg  tuxradar_s05e04.ogg
tuxradar_s04e16.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e10.ogg
tuxradar_s04e19.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e12.ogg
tuxradar_s04e20.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e14.ogg
tuxradar_s04e21.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e17.ogg
tuxradar_s04e22.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e18.ogg
tuxradar_s04e23.ogg

download file...

~/Podcasts/TuxRadar Linux Podcast (Ogg)$ git annex addurl http://www.tuxradar.com/files/podcast/tuxradar_s05e05.ogg
addurl www.tuxradar.com_files_podcast_tuxradar_s05e05.ogg (downloading http://www.tuxradar.com/files/podcast/tuxradar_s05e05.ogg ...) --2013-04-10 21:18:12--  http://www.tuxradar.com/files/podcast/tuxradar_s05e05.ogg
Resolving www.tuxradar.com (www.tuxradar.com)... 80.244.178.150
Connecting to www.tuxradar.com (www.tuxradar.com)|80.244.178.150|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33249291 (32M) [application/ogg]
Saving to: `/home/rob/Podcasts/.git/annex/tmp/URL--http&c%%www.tuxradar.com%files%podcast%tuxradar_s05e05.ogg'

100%[===============================>] 33,249,291   404K/s   in 81s

2013-04-10 21:19:35 (399 KB/s) - `/home/rob/Podcasts/.git/annex/tmp/URL--http&c%%www.tuxradar.com%files%podcast%tuxradar_s05e05.ogg' saved [33249291/33249291]

(checksum...) ok
(Recording state in git...)

file appears to have been downloaded, but isn't there...

~/Podcasts/TuxRadar Linux Podcast (Ogg)$ ls
folder.jpg           tuxradar_s04e24.ogg
tuxradar_s04e09.ogg  tuxradar_s05e01.ogg
tuxradar_s04e11.ogg  tuxradar_s05e02.ogg
tuxradar_s04e13.ogg  tuxradar_s05e03.ogg
tuxradar_s04e15.ogg  tuxradar_s05e04.ogg
tuxradar_s04e16.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e10.ogg
tuxradar_s04e19.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e12.ogg
tuxradar_s04e20.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e14.ogg
tuxradar_s04e21.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e17.ogg
tuxradar_s04e22.ogg  www.tuxradar.com_files_podcast_tuxradar_s04e18.ogg
tuxradar_s04e23.ogg

What is the expected output? What do you see instead?

File should exist in current directory. As you can see from above output, this has worked in the past (with older versions).

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

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

OS: Debian Testing/Unstable

Please provide any additional information below.

The repository in question was created by the assistant and I tried the above with the assistant both running and not running, with no difference. I have also tried downloading other files.

EDIT: formatting

> Bug only affected direct mode. I think it used to work but I broke
> it when fixing another bug in direct mode. [[fixed|done]] --[[Joey]]


code:
### Please describe the problem.

When entering Jabber account data, the assistant responds with:

    Internal Server Error: /etc/resolv.conf does not exist (No such file or directory).

### What steps will reproduce the problem?

Get a jabber account at http://jit.si. Enter your jabber name and password on Android assistant, and click "Use This Account". The dark overlay and progress message appears. After about 30 seconds the browser forwards to the "Internal Server Error: /etc/resolv.conf does not exist (No such file or directory)" page.

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

Android 4.2 on Lenovo 780p. This model is only for sale in China and India and has been rooted, but the original ROM is still on. Often this makes no difference but you might want to confirm with another device.

git-annex version 5.20131127-g736ce5e

### 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="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"
 nickname="Christian"
 subject="Same on CyaogenMod 10.2"
 date="2013-11-29T11:00:58Z"
 content="""
CM10.2 Nightly Build for Sony Experia Mini Pro does show the same behaviour. Creating the resolv.conf does not solve the problem:

    1|root@mango:/etc # touch resolv.conf; ls resolv.conf
    touch resolv.conf; ls resolv.conf
    resolv.conf: No such file or directory

"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawknsDuoV1R2hz6QoCJmMFWLmWgdZfULjMI"
 nickname="Jakob"
 subject="Moto G"
 date="2013-12-02T13:53:55Z"
 content="""
Same proplem on a Moto G - Android 4.3 - not rooted / Stock

running git-annex version 5.20131202-g5b9eb74

Error Message:

    /etc/resolv.conf: openFile: does not exist (No such file or directory)

command-line output:

    Falling back to hardcoded app location; cannot find expected files in /data/app-lib
    git annex webapp
    ex webapp
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.64"
 subject="comment 3"
 date="2013-12-03T17:35:11Z"
 content="""
The dns library used only for srv lookups was trying to use /etc/resolv.conf. I've patched it to use the android getprop command instead to discover the DNS server.

The daily build has already been updated with this fix. I have not tested it completely myself.
"""]]


code:
### Please describe the problem.

On Andorid adding a respository on a remote server (ssh) to an exisiting repository does not work. After selecting "Make unencrypted repository" in the webapp the following error message is displayed:

Internal Server Error
/sdcard/git-annex.home/.ssh/config: setFileMode: permission denied (Operation not permitted)

The file "/sdcard/git-annex.home/.ssh/config" is created and its content seems to be fine. I could not find anything related to file mode in logcat / daemon.log.

### What steps will reproduce the problem?

Add a repository on a remote server to an existing repository. After selecting "Make unencrypted repository" the error messages is displayed.

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

git-annex version 5.20140116-g2d9ec29
Android version 4.4 (running on a Nexus 5)

> I have made this failure to set the file mode not be a fatal error.
> [[fixed|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkViAynw-AW5kjf3w_QDwCVwhPc3k7gY5E"
 nickname="Thomas"
 subject="I see the same fail"
 date="2014-01-29T21:52:18Z"
 content="""
I se the same failure at both my android devices:
Nexus 7, Android 4.4.2, git-annex 5.20140128 and
Xperia phone, Android 4.1.2, git-annex 5.20140108
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnx07B9weuZowXqh--1BDvGw8VM25aXsRw"
 nickname="Matthew"
 subject="comment 2"
 date="2014-02-01T02:44:47Z"
 content="""
Same here, any workarounds?
"""]]


code:
### Please describe the problem.

Seems to not upload files from Android client (set to "Manual mode: only stores files you...") to servers configured to get the files despite "syncing enabled"

Even when I chose "File source:" mode -- it just dropped all locally stored ones and didn't transfer those I have added.

### What steps will reproduce the problem?

Add file to the sdcard (vfat), and see it added to git (annex) but not uploaded

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

Android build as now of Dec 13 I believe

### Please provide any additional information below.

First it just said that nothing to be transfered, I have switched  that remote to "Full backup", web dashboard had "Scanning for files to transfer" for a while, then refreshed with "Synced with" and no file transfers running.  Below is an excerpt from the log

[[!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

(Recording state in git...)
(Recording state in git...)
(Recording state in git...)
add pics/20131217_125740.jpg ok
add pics/20131217_125740.jpg [2013-12-17 16:19:25 EST] Committer: Committing changes to git
[2013-12-17 16:19:25 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Invalid pid specified
Invalid pid specified
warning: no threads support, ignoring --threads
Already up-to-date.
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
   bcb7ed7..3672b38  git-annex -> synced/git-annex
   e8cc37f..052b758  annex/direct/master -> synced/master
Already up-to-date.
[2013-12-17 16:19:29 EST] Committer: Adding 20131217_125726.jpg
ok
(Recording state in git...)
(Recording state in git...)

add pics/20131217_125726.jpg ok
add pics/20131217_125726.jpg [2013-12-17 16:19:30 EST] Committer: Committing changes to git
Invalid pid specified
[2013-12-17 16:19:32 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Already up-to-date.
warning: no threads support, ignoring --threads
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
   3672b38..f914fed  git-annex -> synced/git-annex
   052b758..859d3c6  annex/direct/master -> synced/master
Already up-to-date.
Invalid pid specified
Invalid pid specified
Invalid pid specified

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

previous runs experienced different problems, so may be those could lead to unreported problem here?
e.g. from previous run:

[[!format sh """
[2013-12-17 16:04:44 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Already up-to-date.
warning: no threads support, ignoring --threads
warning: no threads support, ignoring --threads
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
   a889d7b..c9a7466  git-annex -> synced/git-annex
error: Ref refs/heads/synced/git-annex is at c9a74663dc863eb95d316deac4657173c92653df but expected a889d7b335738ef1c4f85da18d1bea337cd36522
remote: error: failed to lock refs/heads/synced/git-annex^[[K
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
 ! [remote rejected] git-annex -> synced/git-annex (failed to lock)
error: failed to push some refs to 'ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/'
Everything up-to-date
Invalid pid specified
[2013-12-17 16:08:34 EST] main: Syncing with vagus.cns.dartmouth.edu_annex
Everything up-to-date
Invalid pid specified
~
]]

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


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.87"
 subject="comment 1"
 date="2013-12-17T23:51:32Z"
 content="""
The \"Invalid pid specified\" seems to point at the problem. (Or it's a nice red herring.) I cannot find this error message in either git-annex or in git.

Enabling debug logging and restarting the assistant should produce a nice log that will both tell us what command it was running when that message showed up, and show some details about its preferred content decisions.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
 nickname="Yaroslav"
 subject="comment 2"
 date="2013-12-18T02:07:46Z"
 content="""
enabled debug logging in the preferences of webapp, clicked on 'restart daemon',  fetched log:

    $> grep -B 1 pid daemon.log
    [2013-12-17 20:51:49 EST] chat: nice [\"ionice\",\"-c3\",\"git-annex\",\"transferkeys\"]
    Invalid pid specified

entire log http://www.onerussian.com/tmp/daemon.log.gz

in the webbrowser page got stuck white without updating, refreshed it and got

    \"Internal Server Error\"
    git-annex: createProcess: runInteractive
    Process: pipe: resource exhausted (Too many open files)

went to terminal, ctrl-c, started again -- seems have managed to start:

    $> grep -B 3 pid daemon.log
    (scanning...) [2013-12-17 20:57:36 EST] Watcher: Performing startup scan
    Already up-to-date.
    Everything up-to-date
    Invalid pid specified

disabled, and then reenabled syncing with vagus, refetched daemon.log to see similar to above message.

New experiment -- added locally yet another file pics/test.jpg which according to whereis was quickly pushed out from my laptop.

Then realized that daemon.log is no longer verbose! (i.e. changes in preferences within webapp didn't persist)  By now on phone it synced git, but didn't download the load (rightfully since I have instructed not to).

ok -- went to enable debug logging  again in webapp -- it was already selected.

in the log now found following

```
    (started...) [2013-12-17 20:59:10 EST] main: Syncing with vagus.cns.dartmouth.edu_annex
    Everything up-to-date
    Invalid pid specified
    [2013-12-17 21:02:37 EST] main: Syncing with vagus.cns.dartmouth.edu_annex
    From ssh://git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex
       c3a5fd6..29b6694  master     -> vagus.cns.dartmouth.edu_annex/master
       d9a09e2..0c3e966  synced/git-annex -> vagus.cns.dartmouth.edu_annex/synced/git-annex
       c3a5fd6..29b6694  synced/master -> vagus.cns.dartmouth.edu_annex/synced/master
    error: Ref refs/heads/annex/direct/master is at 29b6694ee483c4563955bc5ae1ee1664daed7f19 but expected c3a5fd6b7cee1cbd43fbeb5aa4a445a5407067bd
    fatal: Cannot lock the ref 'HEAD'.
    Updating c3a5fd6..29b6694
    Fast-forward

    (merging vagus.cns.dartmouth.edu_annex/synced/git-annex into git-annex...)

    git-annex: /storage/extSdCard/annex/.git/annex/merge/: getDirectoryContents: does not exist (No such file or directory)
    Already up-to-date.
    Already up-to-date.
    [2013-12-17 21:02:41 EST] Committer: Committing changes to git
    [2013-12-17 21:02:42 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
    Everything up-to-date
    [2013-12-17 21:02:43 EST] Committer: Committing changes to git
    [2013-12-17 21:02:45 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
    Everything up-to-date
```
I guess I will just try now to enable debug logging in .git/config while in the terminal on the phone
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
 nickname="Yaroslav"
 subject="comment 3"
 date="2013-12-18T02:21:17Z"
 content="""
ah -- may be that was debug log, but nothing exciting was happening?  .git/config does have annex.debug true

ok -- went to \"switch repositories\", showed the list of my only repository, clicking on it didn't go anywhere... ok - restarted the beast in the terminal, added a new file to the pics/ directory, again -- registered, added to git, synced, did not 'push' the load, and no informative debug messages:

    add pics/earth-daynight.jpg [2013-12-17 21:17:26 EST] Committer: Committing changes to git
    [2013-12-17 21:17:26 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
    Invalid pid specified
    Already up-to-date.
    warning: no threads support, ignoring --threads
    To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
       0c3e966..6d94fd4  git-annex -> synced/git-annex
       29b6694..bbd3fa3  annex/direct/master -> synced/master
    [2013-12-17 21:17:28 EST] Committer: Adding earth-daynight.jpg
    Already up-to-date.
    ok
    (Recording state in git...)
    (Recording state in git...)

so again that pid msg but no debug logging seems to be done.  Is there some other way to enable debug logging? ;)
"""]]


code:
[[!comment format=mdwn
 username="etset"
 ip="188.83.111.161"
 subject="comment 4"
 date="2013-12-29T15:12:43Z"
 content="""
I also can't transfer from and to an Android tablet with the git-annex assistant. The `daemon.log` shows the same error, `Invalid pid specified`, repeated several times.

Enabling the debug log mode always shows lines similar to this one before each \"Invalid pid\" line: `[2013-12-29 14:50:49 WET] chat: nice [\"ionice\", \"-c3\", \"git-annex\", \"transferkeys\"]`.

However, using the `git annex get` and `git annex copy` commands to fetch and send the files from the same tablet work as expected.

I can post the full log later, if needed.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.227"
 subject="reproduced bug"
 date="2013-12-29T21:06:30Z"
 content="""
Debug logs shows that the problem is it tries to run ionice. So fix should be trivial.
"""]]


code:
### Please describe the problem.

In order to handle the fact that the directory where pictures are saved is not configurable on my phone, I set up a second git annex repository with the Repository group "file source".

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

5.20140108-gce9652

### Please provide any additional information below.

In the log, there are many "too many open files" errors like these :

git:createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)

[[!tag moreinfo]]
[[!meta title="too many open files on android"]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="71.80.94.56"
 subject="comment 1"
 date="2014-02-07T18:59:29Z"
 content="""
I guess that this bug report is not about the DCIM/Camera location not being configurable, since that is up to Android, not git-annex.

So, it seems to be a bug report about a file descriptor leak. It would be helpful, if you can reproduce the leak, to look at /proc/$pid/fd/ to see what files git-annex has open.
"""]]


code:
### Please describe the problem.

Launching the Git Annex app on Android, the shell just reads:
[[!format sh """
[Terminal session finished]
"""]]

Attempting to launch /data/data/ga.androidterm/runshell via the adb shell does also not work:
[[!format sh """
/system/bin/sh: /data/data/ga.androidterm/runshell: not found
"""]]

Listing the contents of that directory from the git annex terminal appears to confirm this:
[[!format sh """
u0_a172@android:/data/data/ga.androidterm $ ls
cache
lib
shared_prefs
"""]]

Following the instructions for the similar issue here [[http://git-annex.branchable.com/Android/oldcomments/#comment-4c5a944c1288ddd46108969a4c664584]]:
[[!format sh """
u0_a172@android:/ $ ls -ld /data/data/ga.androidterm
drwxr-x--x u0_a172  u0_a172           2014-04-20 11:12 ga.androidterm
"""]]

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

version 5.20140413 of the Git Annex app (tested using the daily build and regular build).

Samsung Galaxy Tab 3 (GT-P5210) running Android 4.2.2 (without root access).

> [[dup|done]] --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.191"
 subject="comment 1"
 date="2014-04-20T17:16:50Z"
 content="""
From the git-annex terminal, try to run:

/data/data/ga.androidterm/lib/lib.start.so

Paste me any output..
"""]]


code:
[[!comment format=mdwn
 username="cbaines"
 ip="86.166.14.171"
 subject="comment 2"
 date="2014-04-20T19:40:11Z"
 content="""
When I run that, I get:
[[!format sh \"\"\"
/system/bin/sh: /data/data/ga.androidterm/lib/lib.start.so: not found
\"\"\"]]

Which makes some sense, as the file is not there. The following files can be found under /data/data/ga.androidterm:
[[!format sh \"\"\"
/data/data/ga.androidterm/cache/com.android.renderscript.cache/ <- empty directory
/data/data/ga.androidterm/lib/libga-androidterm4.so
/data/data/ga.androidterm/shared_prefs/ga.androidterm_preferences.xml
\"\"\"]]

I tried running libga-androidterm4.so, but I just got Segmentation fault back.

I also tried using logcat to see if I could see anything obvious going wrong when running the app for the first time after installation, but I could not see anything obvious in the logs (there was a lot of noise, so I might of missed something), will anything useful appear with the use of a filter?
"""]]


code:
[[!comment format=mdwn
 username="cbaines"
 ip="86.166.14.171"
 subject="comment 3"
 date="2014-04-20T19:50:12Z"
 content="""
Looking at the contents of the apk for the x86 architecture (which this tablet is), would you expect that file to be there? That file only appears in the /lib/armeabi and not /lib/x86 ?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.191"
 subject="comment 4"
 date="2014-04-20T19:55:59Z"
 content="""
Ok, so the git-annex.apk ships several libraries (and pseudo-libraries), and it seems your version of Android only installed the one that is really an Android java application. I don't know why.

Here's the full list of files that are supposed to be installed in the lib dir. If you can find something about them in the logs, that might help.

I suppose it's possible they were installed to some other location in the android file system (which might be hard to find w/o root.. You could check if git-annex in the app list has a larger installed size than the size of libga-androidterm4.so, that might give a hint.

<pre>
lib.busybox.so
lib.git-annex.so
lib.git-shell.so
lib.git-upload-pack.so
lib.git.so
lib.git.tar.gz.so
lib.gpg.so
lib.rsync.so
lib.runshell.so
lib.ssh-keygen.so
lib.ssh.so
lib.start.so
lib.version.so
libga-androidterm4.so
</pre>

(I just installed the 5.20140414-gb70cd37 autobuild on an android device and it worked ok.)
"""]]


code:
[[!comment format=mdwn
 username="cbaines"
 ip="86.166.14.171"
 subject="comment 5"
 date="2014-04-20T20:20:55Z"
 content="""
I'm guessing you missed my last comment regarding the architecture. Sorry I did not pick this up earlier, but it only came to mind when I had a poke around in the apk?
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.191"
 subject="comment 6"
 date="2014-04-20T20:58:22Z"
 content="""
Yes, that fully explains it. git-annex is a native program and for android it's only built for arm.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.191"
 subject="comment 7"
 date="2014-04-20T20:59:35Z"
 content="""
So, this is a dup of [[todo/Not_working_on_Android-x86]]
"""]]


code:
### Please describe the problem.
I have a repo where some files have utf-8 characters in their names. They are copied without problems between linux-running pcs, but on Android I only get a small, 206 bytes files with the hash data.

### What steps will reproduce the problem?
Add some files with utf-8 characters in names, try to sync to Android

### What version of git-annex are you using? On what operating system?
PC side: tried 5.20140412ubuntu1 from ubuntu repo and standalone tarball 5.20140517-gee56d21, both on Ubuntu Trusy
Android side: Android 4.4.2 on Nexus 7

### Please provide any additional information below.
Part of daemon.log I believe is related to this. Lines starting with Number followed by dot are the filenames, but truncated at first non-ascii character.
I suspect empty lines before the "rsync failed" represent files with names that start with non-ascii character.

[[!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

  rsync failed -- run git annex again to resume file transfer

  rsync failed -- run git annex again to resume file transfer

  rsync failed -- run git annex again to resume file transfer

02. Wyspa W
  rsync failed -- run git annex again to resume file transfer

05. Ponad Krain
  rsync failed -- run git annex again to resume file transfer

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


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawniXLhO9mLn-7EDfawdENZ2fQwlGy5w_oc"
 nickname="Michał"
 subject="Update - 20140529"
 date="2014-06-01T01:36:16Z"
 content="""
Tried with the new 20140529 on Android, same behavior.

One more note: I managed to spot the attempted update in the webapp. The filename that shows up there has all the non-ascii characters replaced by ��� (not truncated as in logs), ex: old/������������.pdf
"""]]


code:
### Please describe the problem.

Install seems to die because /data/app-lib not found. Sorry, I did not copy. Git-annex log is below.

I tried To run git-annex second time, here's what terminal says.

Falling back to hardcoded app location; cannot find expected files in /data/app-lib
git annex webapp
u0_a36@manta:/sdcard/git-annex.home $ git annex webapp
WARNING: linker: git-annex has text relocations. This is wasting memory and is a security risk. Please fix.
error: fchmod on /sdcard/mediashare/.git/config.lock failed: Operation not permitted
error: fchmod on /sdcard/mediashare/.git/config.lock failed: Operation not permitted

From git terminal, can start web viewer, it offers to make repo. I chose /sdcard/mediashare, result is browser fail:

git [Param "config",Param "annex.uuid",Param "380f6ec2-a7b0-43db-9447-f0de1b5a1b5b"] failed

The install did create /sdcard/mediashare. I did have the sdcard directory all along.

I can't say for sure what else is in file system. ES File manager shows /data exists, but it is empty. But tablet not easy to diagnose

### What steps will reproduce the problem?

Install git-annex.apk from website. I downloaded 20140620.

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

Android 4.4.2 on Nexus tablet.

### Please provide any additional information below.

Git-anex-install.log. it is only file in /sdcard/git-annex.home. note it says it is installing to /data/data/.  I may manually create that structure and see if a reinstall ends differently.

[[!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
Installation starting to /data/data/ga.androidterm
1bebb0d66f3f7c5ac4889b86669cab04ebee9bba
installing busybox
installing git-annex
installing git-shell
installing git-upload-pack
installing git
installing gpg
installing rsync
installing ssh
installing ssh-keygen
linking ./bin/git-upload-archive to git
linking ./bin/git-receive-pack to git
linking ./libexec/git-core/git-help to git
linking ./libexec/git-core/git-fsck to git
linking ./libexec/git-core/git-cat-file to git
linking ./libexec/git-core/git-init to git
linking ./libexec/git-core/git-checkout-index to git
linking ./libexec/git-core/git-notes to git
linking ./libexec/git-core/git-grep to git
linking ./libexec/git-core/git-blame to git
linking ./libexec/git-core/git-verify-tag to git
linking ./libexec/git-core/git-write-tree to git
linking ./libexec/git-core/git-log to git
linking ./libexec/git-core/git-stage to git
linking ./libexec/git-core/git-update-ref to git
linking ./libexec/git-core/git-status to git
linking ./libexec/git-core/git-show-branch to git
linking ./libexec/git-core/git-merge-file to git
linking ./libexec/git-core/git-for-each-ref to git
linking ./libexec/git-core/git to git
linking ./libexec/git-core/git-replace to git
linking ./libexec/git-core/git-update-index to git
linking ./libexec/git-core/git-annotate to git
linking ./libexec/git-core/git-patch-id to git
linking ./libexec/git-core/git-merge-recursive to git
linking ./libexec/git-core/git-rm to git
linking ./libexec/git-core/git-ls-tree to git
linking ./libexec/git-core/git-update-server-info to git
linking ./libexec/git-core/git-diff-tree to git
linking ./libexec/git-core/git-merge-tree to git
linking ./libexec/git-core/git-mktag to git
linking ./libexec/git-core/git-rev-list to git
linking ./libexec/git-core/git-column to git
linking ./libexec/git-core/git-apply to git
linking ./libexec/git-core/git-var to git
linking ./libexec/git-core/git-rev-parse to git
linking ./libexec/git-core/git-archive to git
linking ./libexec/git-core/git-verify-pack to git
linking ./libexec/git-core/git-push to git
linking ./libexec/git-core/git-commit to git
linking ./libexec/git-core/git-tag to git
linking ./libexec/git-core/git-pack-refs to git
linking ./libexec/git-core/git-fmt-merge-msg to git
linking ./libexec/git-core/git-fast-export to git
linking ./libexec/git-core/git-remote-ext to git
linking ./libexec/git-core/git-mailsplit to git
linking ./libexec/git-core/git-send-pack to git
linking ./libexec/git-core/git-diff-index to git
linking ./libexec/git-core/git-mailinfo to git
linking ./libexec/git-core/git-revert to git
linking ./libexec/git-core/git-diff-files to git
linking ./libexec/git-core/git-merge-ours to git
linking ./libexec/git-core/git-show-ref to git
linking ./libexec/git-core/git-diff to git
linking ./libexec/git-core/git-clean to git
linking ./libexec/git-core/git-bundle to git
linking ./libexec/git-core/git-check-mailmap to git
linking ./libexec/git-core/git-describe to git
linking ./libexec/git-core/git-branch to git
linking ./libexec/git-core/git-checkout to git
linking ./libexec/git-core/git-name-rev to git
linking ./libexec/git-core/git-gc to git
linking ./libexec/git-core/git-fetch to git
linking ./libexec/git-core/git-whatchanged to git
linking ./libexec/git-core/git-cherry to git
linking ./libexec/git-core/git-reflog to git
linking ./libexec/git-core/git-hash-object to git
linking ./libexec/git-core/git-init-db to git
linking ./libexec/git-core/git-rerere to git
linking ./libexec/git-core/git-reset to git
linking ./libexec/git-core/git-stripspace to git
linking ./libexec/git-core/git-prune to git
linking ./libexec/git-core/git-mktree to git
linking ./libexec/git-core/git-unpack-file to git
linking ./libexec/git-core/git-remote to git
linking ./libexec/git-core/git-commit-tree to git
linking ./libexec/git-core/git-symbolic-ref to git
linking ./libexec/git-core/git-credential to git
linking ./libexec/git-core/git-check-ignore to git
linking ./libexec/git-core/git-shortlog to git
linking ./libexec/git-core/git-fetch-pack to git
linking ./libexec/git-core/git-clone to git
linking ./libexec/git-core/git-mv to git
linking ./libexec/git-core/git-read-tree to git
linking ./libexec/git-core/git-merge-subtree to git
linking ./libexec/git-core/git-ls-remote to git
linking ./libexec/git-core/git-config to git
linking ./libexec/git-core/git-cherry-pick to git
linking ./libexec/git-core/git-merge to git
linking ./libexec/git-core/git-prune-packed to git
linking ./libexec/git-core/git-count-objects to git
linking ./libexec/git-core/git-merge-base to git
linking ./libexec/git-core/git-index-pack to git
linking ./libexec/git-core/git-repack to git
linking ./libexec/git-core/git-show to git
linking ./libexec/git-core/git-fsck-objects to git
linking ./libexec/git-core/git-format-patch to git
linking ./libexec/git-core/git-bisect--helper to git
linking ./libexec/git-core/git-upload-archive to git
linking ./libexec/git-core/git-ls-files to git
linking ./libexec/git-core/git-check-attr to git
linking ./libexec/git-core/git-get-tar-commit-id to git
linking ./libexec/git-core/git-remote-fd to git
linking ./libexec/git-core/git-unpack-objects to git
linking ./libexec/git-core/git-add to git
linking ./libexec/git-core/git-check-ref-format to git
linking ./libexec/git-core/git-merge-index to git
linking ./libexec/git-core/git-pack-objects to git
linking ./libexec/git-core/git-receive-pack to git
linking ./libexec/git-core/git-pack-redundant to git
linking ./libexec/git-core/git-shell to git-shell
linking ./libexec/git-core/git-upload-pack to git-upload-pack
Installation complete

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

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


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.55"
 subject="comment 1"
 date="2014-07-03T20:10:41Z"
 content="""
This is not an installation problem; the /data/app-lib message is a red herring.

Is /sdcard/mediashare a directory that already existed? If so, perhaps it's some \"mediashare\" thing that has a even more crippled filesystem than usual. Seems possible, but I don't know. Want to rule it out..

The actual failure seems to be when git tries to write to its config.lock file, and changes its permissions. This is a recent change in git, commit daa22c6f8da466bd7a438f1bc27375fd737ffcf3, \"config: preserve config file permissions on edits\".

[[!language C \"\"\"
+               if (fchmod(fd, st.st_mode & 07777) < 0) {
+                       error(\"fchmod on %s failed: %s\",
+                               lock->filename, strerror(errno));
+                       ret = CONFIG_NO_WRITE;
+                       goto out_free;
+               }
\"\"\"]]

This seems utterly innocuous; the config file has some mode, and this just sets that same mode back (excluding some high bit flags). But Android goes out of its way to make /sdcard the most craptacular filesystem in use on any Linux system, so I'm not really surprised that it might just refuse all fchmod even when it's a no-op. (This is the only fchmod call currently in git.)

I've patched the bundled git to work around this. Will be a while until there is an updated autobuild..
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.55"
 subject="comment 2"
 date="2014-07-04T17:52:35Z"
 content="""
This problem should be fixed in the most recent daily build of git-annex for android. Testing appreciated.
"""]]


code:
### Please describe the problem.

The armel daily build linked from https://git-annex.branchable.com/install/Linux_standalone/ doesn't seem to work.

When runshell is run as root, it hangs with no output and trying to run git directly from the bin directory gives

"/git: exec: line 2: : Permission denied:."

When run as an ordinary user, it gives

"./runshell: line 40: can't create /root/.ssh/git-annex-shell: Permission denied
chmod: /root/.ssh/git-annex-shell: Permission denied"

### What steps will reproduce the problem?

- Login in to NAS as root via SSH
- Download latest daily build via curl
- Untar, chown -R root:root, and CD in to git-annex.linux
- ./runshell or 'cd bin; ./git"

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

Synology DSM 4.3-3810 and latest nightly build of git-annex.

> The shimming was broken, causing the hang. [[fixed|done]]
>
> (It looks like you somehow forgot to set HOME when becoming the non-root
> user.) --[[Joey]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmZgZuUhZlHpd_AbbcixY0QQiutb2I7GWY"
 nickname="Jimmy"
 subject="Same hang when added to $PATH"
 date="2013-12-21T03:28:07Z"
 content="""
DiskStation> echo $PATH

/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin:/root/git-annex.linux

DiskStation> git-annex-shell

[...hangs...]
"""]]


code:
[[!comment format=mdwn
 username="http://grossmeier.net/"
 nickname="greg"
 subject="comment 2"
 date="2013-12-21T06:27:49Z"
 content="""
Try not as root, see how far that gets you.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmZgZuUhZlHpd_AbbcixY0QQiutb2I7GWY"
 nickname="Jimmy"
 subject="comment 3"
 date="2013-12-21T08:22:28Z"
 content="""
Hi Greg, I tried that and got a permissions error.

\"./runshell: line 40: can't create /root/.ssh/git-annex-shell: Permission denied chmod: /root/.ssh/git-annex-shell: Permission denied\"
"""]]


code:
The assistant web UI says: `SanityCheckerStartup crashed: /home/zerodogg/Delt/.git/annex/tmp/Sak_7.pdf: getFileStatus: does not exist (No such file or directory)` with a «Restart thread»-button. Clicking said button merely makes the error re-appear. The file in question is a broken symlink. Deleting the symlink and then restarting the thread fixes the problem.

I'm not sure what causes said symlink to appear (which has the name of a file that does exist in the annex), but it has done so on several systems accross different distributions here (Fedora 20, Ubuntu 14.04, Archlinux). Perhaps an rsync copies over a symlink instead of a file?

git-annex version: 5.20140517-gee56d21

[[!tag confirmed]]

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


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.176"
 subject="comment 1"
 date="2014-05-30T18:58:56Z"
 content="""
Well, Sak7.pdf is not a git-annex object filename. And .git/annex/tmp used to be used as a general-purpose temp directory, but in recent versions we're moving away from that; it's only supposed to contain git-annex objects.

So, this must be a leftover file from an old version of git-annex. I don't know offhand what would create a symlink in the temp directory. However, the crash is from the code that was added to the assistant to clean up such left behind files. So, I'll fix that code.
"""]]


code:
### Please describe the problem.

The assistant/webapp doesn't drop files from the local (source) repository after transferring it to the 2 backup repositories (numcopies 2), but they are listed with:

    git annex find --want-drop

### What steps will reproduce the problem?

#### mintcream ####

    git init annex
    cd ~/annex
    git commit -m "create" --allow-empty
    git annex init mintcream
    git annex numcopies 2
    git annex group here source
    git config annex.autocommit false
    git annex webapp

#### liquorice ####

    git init annex
    cd ~/annex
    git annex init liquorice
    git annex group here backup

#### candyfloss ####

    git init annex
    cd ~/annex
    git annex init candyfloss
    git annex group here backup

#### mintcream ####

    (add both backup repositories in webapp as "remote repositories")
    (copy files into ~/annex directory)
    git annex add
    git commit -m "add some files"
    (use "sync now" to prod assistant into noticing the commit)

### What was I expecting to happen? ###

The assistant to transfer the files to liquorice and candyfloss, then for the assistant to drop the files from mintcream.

### What actually happened? ###

The assistant transfers the files to liquorice and candyfloss. No files are dropped from mintcream.

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

git-annex version: 5.20140707-g923b436

Arch Linux (git-annex-bin from AUR)

### Please provide any additional information below.

I wish to retain control of the commits on "master" (annex.autocommit false) but want the assistant to handle moving/dropping the files as required in the background.

    git annex drop --auto

works as expected.

> [[done]]; user misconfiguration. --[[Joey]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.2"
 subject="comment 1"
 date="2014-07-10T18:48:17Z"
 content="""
Reproduced. `git annex sync --content` has the same problem.

Of course, both it and the assistant *do* check if files can be dropped. For some reason, it is deciding it is not safe to drop the file.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.2"
 subject="user misconfiguration"
 date="2014-07-10T19:02:00Z"
 content="""
Reason is simple: You manually put the repository into the source group, but its preferred content is not set to \"standard\". No matter what group a repository is in, you have to set its preferred content to something, or git-annex will default to assuming you want the repo to retain all files.

So, `git annex wanted mintcream standard` and away you go. You'll also want to set that for the other 2 repos probably..
"""]]


code:
[[!comment format=mdwn
 username="CandyAngel"
 ip="81.111.193.130"
 subject="comment 3"
 date="2014-07-11T10:41:23Z"
 content="""
Ohhh I see!

I was expecting \"standard\" to be the default because of what vicfg shows..

    # Repository preferred contents
    # (for web)
    #wanted 00000000-0000-0000-0000-000000000001 = standard
    # (for test)
    #wanted 025d4d21-7648-426c-a406-bb7f27688afe = standard

    # Group preferred contents
    # (Used by repositories with \"groupwanted\" in their preferred contents)
    #groupwanted archive = standard
    #groupwanted backup = standard
    #groupwanted client = standard
    #groupwanted incrementalbackup = standard
    #groupwanted manual = standard
    #groupwanted public = standard
    #groupwanted smallarchive = standard
    #groupwanted source = standard
    #groupwanted transfer = standard

In my experience with configuration files, a commented out line like this:

    #wanted 025d4d21-7648-426c-a406-bb7f27688afe = standard

without any \"this is an example\" text above it means \"this is the default setting\". Everything in vicfg looks like it is the current settings, rather than just placeholders..

I understand why you need to set the wanted explicitly (at least from the command line), but the way information is shown in vicfg led me to interact with it incorrectly. Would it be worth adding a disclaimer that commented lines are examples, not defaults? As far as I am aware, the logic I explained above (commented line == default) is the \"norm\" in *nix configuration files, which would make vicfg non-intuitive.

All I need to do now is not be so bothered by how messy the git-annex branch looks when the assistant is running things! :D

Thankies
"""]]


code:
[[!comment format=mdwn
 username="CandyAngel"
 ip="81.111.193.130"
 subject="comment 4"
 date="2014-07-11T10:57:58Z"
 content="""
Actually, I'm still a little confused.

If git-annex was presuming I wanted to keep all the files as you say, why were they listed in `git annex find --want-drop` and dropped by `git annex drop --auto`?

Shouldn't they have been empty and a no-op respectively?

There seems to be a difference in the behaviour between the command line (wanting to and actually dropping the files) and the assistant (wanting to keep them) for the same settings.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.2"
 subject="comment 5"
 date="2014-07-11T18:27:44Z"
 content="""
The assistant defaults to assuming all files are wanted if there's no preferred content settings, while command-line dropping stuff defaults to assuming no files are wanted (or more accurately, that you'll drop anything you don't want and get anything you do) when there's no preferred content settings. So the default differs, but this only matters when not setting preferred contents.

I agree that the vicfg could be misread, so have changed it.
"""]]


code:
### Please describe the problem.

On two hosts, I've configured two separate local repositories (~/foo and ~/bar) with the assistant and added a transfer repository to ~/foo.

While files are kept separate, the configuration seems to get mixed up. This results in all files beeing uploaded to the configured transfer repository.

The reason might be, that informations about ~/bar are included in the configuration of ~/foo (see below).

### What steps will reproduce the problem?

* Create local repository ~/foo on both hosts
* Add transfer repository to ~/foo on both hosts
* Add some files to ~/foo and let it sync
* Create local repository ~/bar and select keep the repositories separate on both hosts
* All files of ~/foo will now be uploaded again to the transfer repository

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

5.20140421~bpo70+1 on Debian 7.5 amd64

### Please provide any additional information below.

*trh@czc4142wfz:~/foo$ git-annex info*

repository mode: direct
trusted repositories: 0
semitrusted repositories: 4
	00000000-0000-0000-0000-000000000001 -- web
 	bd23a5ed-af6e-466d-ac8c-9ea38a220c62 -- trh@r9-y3pll:~/foo
 	cc888105-b6c3-4926-8396-e3870f6bfc05 -- transfer_foo
 	f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 -- here (trh@czc4142wfz:~/foo)
untrusted repositories: 0
transfers in progress: none
available local disk space: 356.11 gigabytes (+1 megabyte reserved)
local annex keys: 2
local annex size: 2.99 gigabytes
annexed files in working tree: 2
size of annexed files in working tree: 2.99 gigabytes
bloom filter size: 16 mebibytes (0% full)
backend usage:
	SHA256E: 4

*trh@czc4142wfz:~/bar$ git-annex info*

repository mode: direct
trusted repositories: 0
semitrusted repositories: 2
	00000000-0000-0000-0000-000000000001 -- web
 	f1478436-cf7b-4a05-91a6-91157ae5e9c4 -- here (trh@czc4142wfz:~/bar)
untrusted repositories: 0
transfers in progress: none
available local disk space: 356.11 gigabytes (+1 megabyte reserved)
local annex keys: 0
local annex size: 0 bytes
annexed files in working tree: 0
size of annexed files in working tree: 0 bytes
bloom filter size: 16 mebibytes (0% full)
backend usage:

*trh@czc4142wfz:~/foo$ git-annex vicfg*

# git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
#   setting field = value

# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@r9-y3pll:~/foo)
#trust bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = semitrusted
# (for transfer_foo)
#trust cc888105-b6c3-4926-8396-e3870f6bfc05 = semitrusted
# (for trh@czc4142wfz:~/foo)
#trust f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = semitrusted

# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for )
group 357eaef4-af1b-491a-a003-01c2d583056e = client
# (for trh@r9-y3pll:~/foo)
group bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = client
# (for )
group f1478436-cf7b-4a05-91a6-91157ae5e9c4 = client
# (for trh@czc4142wfz:~/foo)
group f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = client
# (for transfer_foo)
group cc888105-b6c3-4926-8396-e3870f6bfc05 = transfer
# (for web)
#group 00000000-0000-0000-0000-000000000001 =

# Repository preferred contents
# (for )
wanted 357eaef4-af1b-491a-a003-01c2d583056e = standard
# (for trh@r9-y3pll:~/foo)
wanted bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = standard
# (for transfer_foo)
wanted cc888105-b6c3-4926-8396-e3870f6bfc05 = standard
# (for )
wanted f1478436-cf7b-4a05-91a6-91157ae5e9c4 = standard
# (for trh@czc4142wfz:~/foo)
wanted f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = standard
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard

# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard

# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*

# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#required bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#required cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#required f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =

# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#schedule bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#schedule cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#schedule f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =

**Note: f1478436-cf7b-4a05-91a6-91157ae5e9c4 is id of ~/bar on local host (see below) / 357eaef4-af1b-491a-a003-01c2d583056e is id of ~/bar on r9-y3pll**

*trh@czc4142wfz:~/bar$ git-annex vicfg*

# git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
#   setting field = value

# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@czc4142wfz:~/bar)
#trust f1478436-cf7b-4a05-91a6-91157ae5e9c4 = semitrusted

# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for web)
#group 00000000-0000-0000-0000-000000000001 =
# (for trh@czc4142wfz:~/bar)
#group f1478436-cf7b-4a05-91a6-91157ae5e9c4 =

# Repository preferred contents
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard
# (for trh@czc4142wfz:~/bar)
#wanted f1478436-cf7b-4a05-91a6-91157ae5e9c4 = standard

# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard

# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*

# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@czc4142wfz:~/bar)
#required f1478436-cf7b-4a05-91a6-91157ae5e9c4 =

# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@czc4142wfz:~/bar)
#schedule f1478436-cf7b-4a05-91a6-91157ae5e9c4 =

*trh@r9-y3pll:~/foo$ git-annex info*

repository mode: direct
trusted repositories: 0
semitrusted repositories: 4
	00000000-0000-0000-0000-000000000001 -- web
 	bd23a5ed-af6e-466d-ac8c-9ea38a220c62 -- here (trh@r9-y3pll:~/foo)
 	cc888105-b6c3-4926-8396-e3870f6bfc05 -- transfer_foo
 	f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 -- trh@czc4142wfz:~/foo
untrusted repositories: 0
transfers in progress: none
available local disk space: 280.24 gigabytes (+1 megabyte reserved)
local annex keys: 2
local annex size: 2.99 gigabytes
annexed files in working tree: 2
size of annexed files in working tree: 2.99 gigabytes
bloom filter size: 16 mebibytes (0% full)
backend usage:
	SHA256E: 4

*trh@r9-y3pll:~/bar$ git-annex info*

repository mode: direct
trusted repositories: 0
semitrusted repositories: 2
	00000000-0000-0000-0000-000000000001 -- web
 	357eaef4-af1b-491a-a003-01c2d583056e -- here (trh@r9-y3pll:~/bar)
untrusted repositories: 0
transfers in progress: none
available local disk space: 280.24 gigabytes (+1 megabyte reserved)
local annex keys: 0
local annex size: 0 bytes
annexed files in working tree: 0
size of annexed files in working tree: 0 bytes
bloom filter size: 16 mebibytes (0% full)
backend usage:

*trh@r9-y3pll:~/foo$ git-annex vicfg*

# git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
#   setting field = value

# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@r9-y3pll:~/foo)
#trust bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = semitrusted
# (for transfer_foo)
#trust cc888105-b6c3-4926-8396-e3870f6bfc05 = semitrusted
# (for trh@czc4142wfz:~/foo)
#trust f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = semitrusted

# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for )
group 357eaef4-af1b-491a-a003-01c2d583056e = client
# (for trh@r9-y3pll:~/foo)
group bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = client
# (for )
group f1478436-cf7b-4a05-91a6-91157ae5e9c4 = client
# (for trh@czc4142wfz:~/foo)
group f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = client
# (for transfer_foo)
group cc888105-b6c3-4926-8396-e3870f6bfc05 = transfer
# (for web)
#group 00000000-0000-0000-0000-000000000001 =

# Repository preferred contents
# (for )
wanted 357eaef4-af1b-491a-a003-01c2d583056e = standard
# (for trh@r9-y3pll:~/foo)
wanted bd23a5ed-af6e-466d-ac8c-9ea38a220c62 = standard
# (for transfer_foo)
wanted cc888105-b6c3-4926-8396-e3870f6bfc05 = standard
# (for )
wanted f1478436-cf7b-4a05-91a6-91157ae5e9c4 = standard
# (for trh@czc4142wfz:~/foo)
wanted f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 = standard
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard

# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard

# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*

# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#required bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#required cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#required f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =

# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/foo)
#schedule bd23a5ed-af6e-466d-ac8c-9ea38a220c62 =
# (for transfer_foo)
#schedule cc888105-b6c3-4926-8396-e3870f6bfc05 =
# (for trh@czc4142wfz:~/foo)
#schedule f3b332fd-4b7a-4a5b-b077-8f13d3d9a407 =

*trh@r9-y3pll:~/bar$ git-annex vicfg*

# git-annex configuration
#
# Changes saved to this file will be recorded in the git-annex branch.
#
# Lines in this file have the format:
#   setting field = value

# Repository trust configuration
# (Valid trust levels: trusted semitrusted untrusted dead)
# (for web)
#trust 00000000-0000-0000-0000-000000000001 = semitrusted
# (for trh@r9-y3pll:~/bar)
#trust 357eaef4-af1b-491a-a003-01c2d583056e = semitrusted

# Repository groups
# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
# (Separate group names with spaces)
# (for web)
#group 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/bar)
#group 357eaef4-af1b-491a-a003-01c2d583056e =

# Repository preferred contents
# (for web)
#wanted 00000000-0000-0000-0000-000000000001 = standard
# (for trh@r9-y3pll:~/bar)
#wanted 357eaef4-af1b-491a-a003-01c2d583056e = standard

# Group preferred contents
# (Used by repositories with "groupwanted" in their preferred contents)
#groupwanted archive = standard
#groupwanted backup = standard
#groupwanted client = standard
#groupwanted incrementalbackup = standard
#groupwanted manual = standard
#groupwanted public = standard
#groupwanted smallarchive = standard
#groupwanted source = standard
#groupwanted transfer = standard
#groupwanted unwanted = standard

# Standard preferred contents
# (Used by wanted or groupwanted expressions containing "standard")
# (For reference only; built-in and cannot be changed!)
# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
# standard backup = include=* or unused
# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
# standard source = not (copies=1)
# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
# standard public = inpreferreddir
# standard unwanted = exclude=*

# Repository required contents
# (for web)
#required 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/bar)
#required 357eaef4-af1b-491a-a003-01c2d583056e =

# Scheduled activities
# (Separate multiple activities with "; ")
# (for web)
#schedule 00000000-0000-0000-0000-000000000001 =
# (for trh@r9-y3pll:~/bar)
#schedule 357eaef4-af1b-491a-a003-01c2d583056e =

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


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.176"
 subject="comment 1"
 date="2014-05-29T18:21:30Z"
 content="""
As far as I can understand the description (which has an lot of different \"foo\"'s in it that seem to refer to different things?) -- This is the assistant behaving as designed: Any time two repositories are pointed at the same transfer repository, or removable drive repository, etc, they will unify and share all their files.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmi0jblSiI4c5-EswqKw4PXkx5M4fuVvdk"
 nickname="Henry"
 subject="comment 2"
 date="2014-05-29T19:10:08Z"
 content="""
I'm using the same folder name on different hosts. So yes, ~/foo exists 3 times. Let me try to clarify it:

<pre>
Client        Transfer           Client
r9-y3pll      edhp-transfer      czc4142wfz
~/foo     <-> ~/foo          <-> ~/foo
~/bar                            ~/bar
</pre>

So, I have two clients and one transfer server. Both clients have two local repositories ~/foo and ~/bar.

The transfer repository has only be configured to the ~/foo client repositories, but not to the ~/bar repositories.

But for some reason, the ~/foo repositories know about the ~/bar repositories (see the id's of the git-annex vicfg output for ~/foo repositories above) and keep uploading files to the transfer repository, even I did select keep the repositories separate on both hosts.

"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.176"
 subject="comment 3"
 date="2014-05-29T19:14:51Z"
 content="""
Are you using XMPP?

There's no way for the foo repositories to learn about the bar repositories unless one of the foo repositories has a remote that is either one of the bar repositories, or that one of the bar repositories points to.
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmi0jblSiI4c5-EswqKw4PXkx5M4fuVvdk"
 nickname="Henry"
 subject="comment 4"
 date="2014-05-29T20:10:15Z"
 content="""
No, I haven't configured XMPP yet.

I just tried something else:

Within assistant I've switched to repository ~bar and then added another repository ~/foobar and again selected keep the repositories separate.

The result is, ~/bar knows (vicfg) about ~/foobar, but ~/foo doesn't. It seems to me, that when adding another local repository, the new repository gets known to the currently selected repository.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.176"
 subject="comment 5"
 date="2014-05-29T20:46:47Z"
 content="""
Ok, reproduced that.

Webapp seems to be setting up the newly created repository's group and preferred content settings inside the current repository. The 2 repositories are not otherwise linked or sharing data in any way, so this the impact is limited to 2 lines that won't affect anything being committed to the git-annex branch, and to the newly created repository not defaulting to being in the client group or having the standard preferred content setting (which can easily be fixed with the webapp).
"""]]


code:
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawmi0jblSiI4c5-EswqKw4PXkx5M4fuVvdk"
 nickname="Henry"
 subject="comment 6"
 date="2014-06-11T16:31:09Z"
 content="""
I've just installed 5.20140606 from sid and the problem is gone :-)

Now hoping that this or one of the next release will make it into wheezy backports ;-)

Thank you for your great work and support and sorry for my late feedback.
"""]]


code:
Setup:

* fresh install of Debian Wheezy with git-annex 4.20130227 pulled in from unstable

Steps:

* clone existing repository and activate assistant
* Have USB drive, U, with repository group `backup` and preferred content string `standard`

Expected:

* Assistant never ever tries to drop anything from U

Actual:

* Assistant immediately tries to drop files from U; fortunately I didn't have the USB drive plugged in
* Changing the preferred content string of U to `present or include=*` stops the dropping, but this was never required before

Additional information:

* The files that the Assistant started trying to drop were, I believe, the first (alphabetically) files in my repository to contain non-ascii characters in their file names (some French accented letters)

Thanks.

> The non-ascii characters are the giveaway: For 1 version, git-annex used
> a regex library that failed to ever match non-ascii characters. So it
> thought backup repos, which match "*" with a regex, wanted no such files.
> This is [[fixed|done]]. --[[Joey]]


code:
[[!comment format=mdwn
 username="http://edheil.wordpress.com/"
 ip="173.162.44.162"
 subject="comment 1"
 date="2013-03-12T14:25:16Z"
 content="""
This sounds very similar to [[http://git-annex.branchable.com/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/]]; my client was pulling in content prior to dropping it from a \"backup\" repo on a USB drive.
"""]]


code:
The assistant from the standalone 64bit build crashes upon startup.

### Version information

     [0 zerodogg@firefly annexed]$ git annex version
     git-annex version: 5.20131230-g4aa88d8
     build flags: Assistant Webapp Pairing 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 external
     local repository version: 5
     supported repository version: 5
     upgrade supported from repository versions: 0 1 2 4
     [0 zerodogg@firefly annexed]$ uname -a
     Linux firefly 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
     [0 zerodogg@firefly annexed]$ cat /etc/fedora-release
     Fedora release 20 (Heisenbug)
     [0 zerodogg@firefly annexed]$

### Error

     [0 zerodogg@firefly annexed]$ git annex webapp
     Launching web browser on file:///home/zerodogg/Documents/annexed/.git/annex/webapp.html

     (process:6045): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
     libgcc_s.so.1 must be installed for pthread_cancel to work
     error: git-annex died of signal 6
     [134 zerodogg@firefly annexed]$ ls -l /usr/lib64/libgcc_s.so.1
     lrwxrwxrwx. 1 root root 28 2013-12-18 10:54 /usr/lib64/libgcc_s.so.1 -> libgcc_s-4.8.2-20131212.so.1
     [0 zerodogg@firefly annexed]$

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


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.227"
 subject="comment 1"
 date="2013-12-31T18:55:36Z"
 content="""
You seem to show `git-annex version` being run without crashing, so it does not seem to crash on startup generally.

Also, this build of git-annex is not linked to libgcc at all.

Also, git-annex seems to start your web browser.

So, it seems more likely that your web browser is crashing than that git-annex is crashing. The web browser crash may be taking out git-annex in some way.
"""]]


code:
[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.227"
 subject="comment 2"
 date="2013-12-31T19:11:16Z"
 content="""
I've verified that git-annex runs the web browser in a cleaned up environment, that does not, for example, have the `LD_LIBRARY_PATH` used by the bundle set.

I checked this by making a ~/dumpenv script:

[[!format sh \"\"\"
#!/bin/sh
set
echo \"$@\"
\"\"\"]]

Then `chmod +x ~/dumpenv; git config web.browser ~/dumpenv` and `git annex webapp` to run it.

I did notice that it set `GCONV_PATH=''`, rather than unsetting that variable, and have made a commit fixing that. But I doubt that caused this problem.

The \"g_slice_set_config: assertion 'sys_page_size == 0\" seems to be a Mozilla bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=672671>, and does not seem to be related, probably firefox is printing that well before crashing.

It looks like libc can somehow demand-load libgcc_s.so, so I have force included that into the bundle. Don't know if that will help. Will be available in autobuilds in an hour.
"""]]


code:
[[!comment format=mdwn
 username="EskildHustvedt"
 ip="80.202.213.197"
 subject="comment 3"
 date="2014-01-01T02:36:47Z"
 content="""
The browser doesn't crash, it stays up, though the git annex page disappears (replaced by the usual \"connection refused\" page from firefox) after a few seconds (ie. \"git annex webapp\" starts the browser, the git-annex page appears for a few seconds, and then it disappears as git-annex crashes, leaving the browser still running).

The latest daily build appears to work now though: git-annex version: 5.20140101-gf9e5218, so that seems to have done the trick.
"""]]