From 13fd7cf00e948330048ff8f13d1bb3ed40e1b33f Mon Sep 17 00:00:00 2001 From: anarcat Date: Tue, 4 Dec 2018 01:50:29 +0000 Subject: [PATCH] some user confusion with v7 repos --- ...ails_to_fetch_files_on_FAT_filesystem.mdwn | 120 ++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn new file mode 100644 index 0000000000..e03ace7936 --- /dev/null +++ b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn @@ -0,0 +1,120 @@ +### 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` + 4. `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]] + +### 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! :)