Please describe the problem.

I cannot figure out how to fetch file from a new v7 clone on a FAT filesystem.

What steps will reproduce the problem?

  1. mount external USB drive named KINGSTON
  2. cd /media/anarcat/KINGSTON
  3. git clone ~/git-annex-repo git -C git-annex-repo annex info

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

7.20181121 on Debian buster.

Please provide any additional information below.

I have a small-ish repository (1.2GB) that I was hoping to more naturally clone onto an external USB stick. It took a surprisingly long time, so at first I thought it was actually fetching the files as well:

anarcat@curie:KINGSTON$ git clone ~/Pictures/calendes
Clonage dans 'calendes'...
fait.
Extraction des fichiers: 100% (174/174), fait.
"git clone ~/Pictures/calendes" took 4 mins 54 secs

But no, the repository is actually quite small:

$ du -shL calendes
47M calendes

Okay, let's figure out what's on there:

anarcat@curie:calendes$ git annex info

  Detected a filesystem without fifo support.

  Disabling ssh connection caching.

  Detected a crippled filesystem.
(merging origin/git-annex into git-annex...)
(recording state in git...)

  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.

Basculement sur la branche 'adjusted/master(unlocked)'
repository mode: indirect
trusted repositories: 0
semitrusted repositories: 7
    00000000-0000-0000-0000-000000000001 -- web
    00000000-0000-0000-0000-000000000002 -- bittorrent
    012c0223-72a6-4215-92fc-d130420c74b4 -- anarcat@curie:/media/anarcat/KINGSTON/calendes [here]
    383d0375-492f-47a3-9ab0-5e98cb8dae7e -- anarcat@angela:~/Pictures/calendes
    39538a65-dfdf-461a-80a6-5bba368eac8d -- anarcat@curie:~/Pictures/calendes [origin]
    434fe592-63af-4a76-8ee0-25ae70c66dff -- anarcat@marcos:/var/www/calendes
    c7cdb1a3-a84f-49b1-a50d-95db16be7313 -- anarcat@marcos:~/Pictures/calendes
untrusted repositories: 0
transfers in progress: none
available local disk space: 15.41 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: 32 mebibytes (0% full)
backend usage:

Hmm.. Okay, adjusted branches. Not sure how that works, but let's try it out:

anarcat@curie:calendes$ git annex get
anarcat@curie:calendes$ git annex get pictures/2018-01/DSCF1012.RAF
anarcat@curie:calendes$

Hmm... That does nothing. Okay, reading back git-annex-adjust, it says that sync --content should work:

anarcat@curie:calendes$ git annex sync --content
commit 
Sur la branche adjusted/master(unlocked)
rien à valider, la copie de travail est propre
ok
pull origin 
ok
push origin 
Énumération des objets: 8, fait.
Décompte des objets: 100% (8/8), fait.
Compression par delta en utilisant jusqu'à 4 fils d'exécution
Compression des objets: 100% (5/5), fait.
Écriture des objets: 100% (6/6), 714 bytes | 714.00 KiB/s, fait.
Total 6 (delta 2), réutilisés 1 (delta 0)
To /home/anarcat/Pictures/calendes
   a0b9ba9..490f30e  master -> synced/master
 * [new branch]      git-annex -> synced/git-annex
ok

(Ah crap, I forgot --no-push and now I need to mark that thing as dead.)

Okay, that didn't work either: the files are still missing from the USB key. I have also tried to git annex copy --to KINGSTON after setting up the remote: the copy goes fine, but the file is still absent, according to git annex whereis from the KINGSTON repo's perspective, and the file in the worktree is still just the pointer to the internal datastructures.

At that point I gave up and copied the files directly using a file manager because, thankfully, the new v7 mode seems to work well enough for me to be able to just copy files that way now. :)

How do I fetch those files anyways? -- anarcat

Ugh. Obviously, problem between keyboard and chair here. :( Turns out the clone didn't create a v7 repository, and a simple git annex upgrade on the clone fixed the problem. The Entering an adjusted branch warning threw me off - I thought it was an indicator that the init stage (correctly?) detected it should be in v7 mode. I would have expected a v5 repo to be in classical direct mode here, not this weird state where it's "partly v7". Maybe I misunderstood something?

Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

I am a faithful user of git-annex since almost the beginning, and it's serving me incredibly well. The new v7 mode seems awesome and I have high hopes it will solve a ton of workflow issues I have identified over time with git-annex. So congratulations on that awesome work! :)

fixed in master, I think. --Joey