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

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

Browse source
This commit is contained in:
Joey Hess 2024-04-09 12:59:01 -04:00
commit 00593523c6
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 38 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
doc/bugs/available_space_miscomputed_on_large_macOS_volume/comment_1_cb1e92ef1412e68c12f6a1c9a10a7414._comment Normal file
View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="mdekstrand"
avatar="http://cdn.libravatar.org/avatar/0acb8a6c848d39aa53d94bd81239b034"
subject="Update after transferring more files"
date="2024-04-09T14:45:07Z"
content="""
After transferring many more files with `--force`, `git annex info` reports an available space of 17.46 terabytes, with following actual space:
```
$ df -h .
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk5s1 98Ti 2.3Ti 96Ti 3% 75k 1.0T 0% /Volumes/ABYSS
```
I suspect the problem is either an integer overflow of some kind, or an integer size/precision error reading from the disk space struct in the disk space library.
"""]]

14
doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_2_e0f6d78620a89f60010607b37328f754._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="nobodyinperson"
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
subject="when someone names files like keys, they probably want trouble 🙃"
date="2024-04-09T10:43:16Z"
content="""
> skip exporting any files that have names that look like annex keys.
A general regex for a key looks like `^[A-Z0-9]+(?:-[a-z]\d+)*--.+$`, right? This seems like there would be many possible false positives that would not be exported, like `GIT--The Book.pdf`.
I can't see a situation where git annex would produce or rename files named like their (or another) key. So if someone deliberately names a file like `SHA256E-s31390--f50d7ac4c6b9031379986bc362fcefb65f1e52621ce1708d537e740fefc59cc0.mp3` and then exports it to such a versioned tree, I'd be fine with overwriting. After all, export remotes aren't primarily for full backups, rather for access convenience and filesystem limitations, right?
I don't know if it's a problem internally for git-annex though when an export suddenly causes keys to vanish from the remote, but I guess your git-tree-diffing automatically takes care of that?
"""]]

8
doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_3_19e77a51911d3c2d39a558162223e78e._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="nobodyinperson"
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
subject="or use numcopies for safety"
date="2024-04-09T10:48:10Z"
content="""
Or, even better: If such an export action would cause data loss, the potentially vanishing keys would be known, because they reside in a git-tree that you diff anyway, right? Git annex could then apply its usual logic of 'I shall never execute an action that reduces a file's copies below `$numcopies`' and error out with an explanation. That feels right and consistent with git annex' typical behavior.
"""]]