mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2022-11-14 12:04:51 -04:00
commit 80ad41f9f0
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
7 changed files with 91 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__.mdwn Normal file
View file

@ -0,0 +1,3 @@
While going through the docs, I found that `sync --cleanup` will remove the `synced/*` branches after completing a sync.
Is there any reason why it would be a bad idea to use that flag as a default for my own use. I like the clean aspect of not having those branches around, but I don't know if there's a good reason why I would want to keep them.

14
doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__.mdwn Normal file
View file

@ -0,0 +1,14 @@
I find that it's possible for a repo to not get the content that it wants to have. It happens if the repo only points to remotes that don't have the content.
`git annex get` will fail:
$ git annex get --want-get
get foo (not available)
Maybe add some of these git remotes (git remote add ...):
6ac12bd5-b585-4884-b0fe-a48fdc1b6365 -- b
failed
get: 1 failed
But `git annex sync --content` passes, despite not getting any of the wanted content.
Is there a way to make `git annex sync --content` error if it can't fetch wanted content, the way `git annex get` does?

10
doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_1_41d3a4774dd5ada5036247eb6f562392._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="pat"
avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
subject="comment 1"
date="2022-11-12T02:50:07Z"
content="""
I guess I can `git annex sync --content && git annex get --auto` to make sure I get the content I want. Although at that point, it's probably better to do `git annex sync && git annex get --auto && git annex drop --auto`. I was expecting `sync` to handle the auto get/drop - which it usually does. But it silently passes even when it doesn't get the wanted content.
Perhaps I should think of `sync` as a \"best effort\" mode? That is, it will download available content, but I shouldn't rely on it to download all wanted content - `get` is the job for that.
"""]]

38
doc/forum/othertmp__58___createDirectory__58___already_exists.mdwn Normal file
View file

@ -0,0 +1,38 @@
Through no fault of Git Annex's, my drive lost power in the middle of a `git annex add`, and seems to have experienced corruption.
(If it matters, here's the log of what was happening when the drive powered off:)
```
# [...snip...]
add disk/DCIM/101_FUJI/DSCF3929.MOV
ok
add disk/DCIM/101_FUJI/DSCF3930.MOV
ok
add disk/DCIM/101_FUJI/DSCF3931.MOV
0% 31.98 KiB 67 MiB/s 5s
git-annex: ../.git/annex/othertmp/ingest-DSCF3931423025-19.MOV: hGetBuf: hardware fault (Input/output error)
failed
fatal: not a git repository: '../.git'
fatal: unable to access '../.git/config': Input/output error
git-annex: ../.git/annex: createDirectory: hardware fault (Input/output error)
```
Right after it happened, I tried to check on the data and got this error:
```
$ git annex fsck
fatal: /media/foo/bar/.git/annex/index: index file open failed: Structure needs cleaning
git-annex: fd:13: hPutBuf: resource vanished (Broken pipe)
```
I fixed this (I hope) with an `fsck` of the drive (not a `git fsck` or `git annex fsck` - an actual `fsck` to repair the filesystem). Now I want to check that everything's okay with the data, and I run:
```
$ git annex fsck
git-annex: .git/annex/othertmp: createDirectory: already exists (File exists)
```
How can I get past this error?
Thanks!!

12
doc/forum/othertmp__58___createDirectory__58___already_exists/comment_1_6fb34a361417e4cac08edc20fd2bc3e7._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="amindfv@97236fbaab6048ce6805b2737b27dd7f1cd51da4"
nickname="amindfv"
avatar="http://cdn.libravatar.org/avatar/a82f30bc12d79fee2d142021af8e9aa0"
subject="comment 1"
date="2022-11-10T21:29:33Z"
content="""
If it matters for the answer, the data I was in the middle of `git annex add`-ing is replaceable. I.e. I'd be perfectly happy to bring my repo back to the state before the `add` and simply copy the data over again and then `add` it again.
Also my version is 8.20210223
"""]]

1
doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files.mdwn Normal file
View file

@ -0,0 +1 @@
Some filesystems, like BTRFS or ZFS have copy on write support, which means that if files are copied in a special way they share sectors until one of the files is edited. Implementing support would make files take up less space if they are in unlocked mode and not significantly edited.

13
doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files/comment_1_52db92711e28abb0eb7a346646b91573._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="lena.wildervanck@4b6aac156870f72a36b090e210e4747f702b69cb"
nickname="lena.wildervanck"
avatar="http://cdn.libravatar.org/avatar/8a423528476e6f6dc6a06588b5bbf457"
subject="comment 1"
date="2022-11-13T19:03:48Z"
content="""
Oh, nvm, there already seem to be some references in the code to it.
Maybe it should be added that it does that under [[https://git-annex.branchable.com/tips/unlocked_files/]] under using less disk space?
Also, macOS uses a `-c` flag instead of `reflink`, according to [the cp man page](https://www.unix.com/man-page/mojave/1/cp/).
"""]]