and I would still maintain my view that removing intermediate directory withing .git/annex/objects whose current roles is simply to provide read-only protection might half the burden on the underlying file system, either annex repo(s) are multitude or a single one [1]. lean view [2] could also be of good use as well[2]. Similar exercises with simulated annex'es with >5M files also "helped" to identify problems with ZOL (ZFS on Linux) caching suggesting that even mere handling of such vast arrays of tiny files (as dead symlinks) might give filesystems a good test, so the leaner impact would be -- the better.

[1] e.g. https://github.com/datalad/datalad/issues/32#issuecomment-70523036 [2] https://github.com/datalad/datalad/issues/25

You cannot use a UUID like that. How is git-anndx supposed to know where that UUID is, or how to access it?

You do not use git-annex initremote with normal git remotes, only special remotes.

Set up a git remote, and use git-annex get --from with that.

git remote add ssh://someplace/path/to/repo

git-annex will then figure out that that git remote is the one with that UUID, and be able to use it.

Names of git remotes are completely separate from descriptions of git-annex repositories, which is what git-annex info displays.

AFAIK, all the documentation is clear about the several things that you seem to have gotten confused about. Pointers to any places in the documentation that are confusing about these matters are appreciated..

That's exactly what I was looking for, Thanks!

It easy to setup. And it seems like as good a "canned" solution as box.net or whatever. I don't know if I would use it for sensitive stuff, but for a couple of repos, it makes sense to use it.

There seems to be some support for creating new projects (which I assume is repos) here.

What I'm seeing is the unicode arrow is replaced with 0092 and the elipsis with &. It's losing the other byte.

The problem seems to be in the base64 encoding that's done, when the metadata value contains spaces or a few other problem characters. These same unicode characters roundtrip through without a problem when not embedded in a string with spaces.

*Utility.Base64> let s = "…"
*Utility.Base64> (s, fromB64 $ toB64 s)
("\8230","&")

git-annex also uses base64 for encoding some creds (and for tagged pushes over XMPP, but only the JID is encoded).

The real culprit is the use of w82s, which doesn't handle multi-byte characters. I can easily fix this by using encodeW8 instead. Audited git-annex for other problem w82s uses and don't see any, so will only need to fix this once.

Added a quickcheck test for fromB64 . toB64 roundtripping.

Unfortunately, the entered unicode characters didn't get saved right, so git-annex can do nothing to fix data that was already entered.

This uses ssh, so the repository address can be pasted into the webapp as a ssh server, and it should work already.

It probably does make sense to add gitlab.com as a canned solution alongside box.com and rsync.net in the webapp.

Since the remote will be a full git repository, it should prompt the user if they want to enable gcrypt to encrypt all the content client-side.

If gitlab has a reasonable API for creating a new repository, the webapp could optionally use that, instead of needing the user to create one themselves.

Not related to git-annex, but I was just wondering: What window manager are you using on the first machine? Looks like a tile windows manager but you are using XFCE?!

Look for ".gitattributes" files in http://git-annex.branchable.com/walkthrough/backups/ and the "annex.numcopies" option to use inside these files. You can place the files at any location.

Ooops, the formatting got all messed up. Here it is again:

I am confused by the differences in the time between updates of different repositories in the same machines and of the same repository in different machines. I am using the assistant (in all machines, 'git annex assitant --autostart').

For instance, I have three machines synced as

A <-> B <-> C

and I have two directories being synced. The configuration (except for directory names) is the same and looks like

[annex]
        uuid = something
        version = 5
        direct = true
        autoupgrade = true
        autocommit = true
        startupscan = true
[remote "machine_repo"]
        url = ssh://xxxxxx/~/repo/
        fetch = +refs/heads/*:refs/remotes/machine_repo/*
        annex-uuid = xxxxxxxxxxxxx

I modify or add a file in one of the directories in A, and it quickly (less than 30 seconds) appears in B and shortly after that in C.

In another directory, however, more than 30 minutes can go by without C ever changing (even if B gets the change almost immediately). Looking at the logs I cannot understand what is happening. This is the case of a file, A_sentinel_file_A, created at 01:46.

In B (where it appears almost immediately) I can see

[2015-03-02 01:46:17 CET] Pusher: Syncing with 123.456.789.101_somedir 
To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
   794df9f..ae8c3f0  git-annex -> synced/git-annex
Automatic merge went well; stopped before committing as requested
[2015-03-02 01:47:03 CET] Committer: Committing changes to git
[2015-03-02 01:47:03 CET] Pusher: Syncing with 123.456.789.101_somedir 

A_sentinel_file_A
             18 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
[2015-03-02 01:47:04 CET] Transferrer: Uploaded A_sentinel_file_A
To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
   ae8c3f0..b043335  git-annex -> synced/git-annex
   75269bc..b61c7a5  annex/direct/master -> synced/master
[2015-03-02 01:47:04 CET] Committer: Committing changes to git
[2015-03-02 01:47:06 CET] Pusher: Syncing with 123.456.789.101_somedir 
To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
   b043335..fc9279c  git-annex -> synced/git-annex

And in C (the machine with IP 123.456.789.101, above) I can see

[2015-03-02 01:46:13 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   593d908..794df9f  git-annex  -> Machine_B_somedir/git-annex
   593d908..235149d  synced/git-annex -> Machine_B_somedir/synced/git-annex
   a1596b3..75269bc  synced/master -> Machine_B_somedir/synced/master
[2015-03-02 01:46:17 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   a1596b3..75269bc  annex/direct/master -> Machine_B_somedir/annex/direct/master
   794df9f..ae8c3f0  git-annex  -> Machine_B_somedir/git-annex
   a1596b3..75269bc  master     -> Machine_B_somedir/master
[2015-03-02 01:46:27 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   ae8c3f0..632caa4  git-annex  -> Machine_B_somedir/git-annex
   235149d..632caa4  synced/git-annex -> Machine_B_somedir/synced/git-annex
[2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   632caa4..56ac968  synced/git-annex -> Machine_B_somedir/synced/git-annex
   75269bc..b61c7a5  synced/master -> Machine_B_somedir/synced/master
[2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   632caa4..b043335  git-annex  -> Machine_B_somedir/git-annex
[2015-03-02 01:47:07 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   75269bc..b61c7a5  annex/direct/master -> Machine_B_somedir/annex/direct/master
   b043335..fc9279c  git-annex  -> Machine_B_somedir/git-annex
   75269bc..b61c7a5  master     -> Machine_B_somedir/master
[2015-03-02 01:47:15 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   fc9279c..a4642a8  git-annex  -> Machine_B_somedir/git-annex
   56ac968..a4642a8  synced/git-annex -> Machine_B_somedir/synced/git-annex
(merging synced/git-annex Machine_B_somedir/git-annex into git-annex...)
(recording state in git...)
[2015-03-02 02:17:23 CET] RemoteControl: Syncing with Machine_B_somedir 
From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
   a4642a8..bfaba72  git-annex  -> Machine_B_somedir/git-annex
   a4642a8..bfaba72  synced/git-annex -> Machine_B_somedir/synced/git-annex
   b61c7a5..29ff91e  synced/master -> Machine_B_somedir/synced/master   

Why did Machine C did not show the updated file at 01:47, which is when, I think, machine B pushes it there? Or at 02:17 when both machines again seem to talk to each other? Regardless, at 02:27 the file still was not there. Yes, of course, if I issue a

git annex sync --content

then the file is shown in Machine C. But I should not need to do that.

In contrast, as I said, there is another directory, with identical configuration, where these things do not happen and changes show immediately (both directories, for now, only have tiny test files).

But is there a way to have the changes in one node (the "read only") discarded when there are changes in the remote, so that the new version in the remote is propagated to the read only node? So I guess what I'd like is something like update-changes-from-others.sh (Like sync, but don't commit any local changes. Merge them like sync, don't discard) but without the merging, so discarding any changes as soon as a new version appears in the remote.

I've tried the remote.foo.annex-readonly = true in Android but I am not getting my intended behavior.

For instance, suppose a computer and a Android device (but with direct mode, since working with assistant)

• Create file in computer
• Let it appear in Android
• Modify in Android; this change apparently does not propagate back to the computer.
• Modify again in computer; sometime later one gets a conflict (file.variant-xxxx and file-variant-yyyy, with the computer getting one of the conflicts as a link that points nowhere).

Adding autocommit = false does not help either.