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

This commit is contained in:
Joey Hess 2020-09-02 12:25:52 -04:00
commit 5a9f518a42
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 152 additions and 0 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 2"
date="2020-09-02T02:53:21Z"
content="""
yep, would have been nice if git-annex either asked youtube-dl or just figured out itself to map URL to `https://www.youtube.com/feeds/videos.xml?playlist_id=ID` to get a feed for a copy/pasted playlist URL.
"""]]

View file

@ -0,0 +1,49 @@
### Please describe the problem.
### What steps will reproduce the problem?
```touch foo
chmod 755 foo
git-annex add foo
ls -lL foo
```
### What version of git-annex are you using? On what operating system?
```
git-annex version: 7.20190129
build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
operating system: linux x86_64
supported repository versions: 5 7
upgrade supported from repository versions: 0 1 2 3 4 5 6
local repository version: 5
```
### Please provide any additional information below.
```
$ touch foo
$ chmod 755 foo
$ ls -l foo
-rwxr-xr-x 1 hans hans 0 sep 2 15:00 foo
$ git-annex add foo
add foo ok
(recording state in git...)
$ ls -lL foo
-rw-rw-rw- 1 hans hans 65 jul 24 2015 foo
```
NB: the date of the file is now jul 24 2015, but I created foo 2 sep, so what happened here? (This annex is old, so I might have created a file foo in 2015, but that should not intere with this new file).
I have my private binaries in ~/annex/bin and this has worked well for many years, but recently it stopped working.
### 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've used git-annex since summer 2012, it's great :-)

View file

@ -0,0 +1,74 @@
A [DataLad issue](https://github.com/datalad/datalad/issues/4795) was
raised about users inadvertently corrupting locked files. That led to
an example where a user could copy corrupted content over to a special
remote, and the content isn't flagged until a `get` call. (A slightly
different example, based on a directory remote and without
`exporttree=yes`, is included below.)
In the case of a regular remote, the `copy` call would fail earlier
with
```
verification of content failed
failed to send content to remote
verification of content failed
failed to send content to remote
failed
git-annex: copy: 1 failed
```
Should something similar happen when copying or exporting to a special
remote? Perhaps verification before transfer to a special remote
isn't worth it, but the successful transfer surprised me given the
behavior when transferring to regular remotes.
[[!format sh """
cd "$(mktemp -d "${TMPDIR:-/tmp}"/dl-XXXXXXX)"
mkdir d
git init a
(
cd a
git annex init
echo one >one
git annex add one
git commit -mone
one_resolved=$(readlink -f one)
chmod +w $one_resolved
echo more >>$one_resolved
chmod -w $one_resolved
git annex initremote d type=directory directory="$PWD"/../d encryption=none
git annex copy --to=d
git annex drop one
git annex get one
)
"""]]
```
[...]
copy one (to d...)
ok
(recording state in git...)
drop one ok
(recording state in git...)
get one (from d...)
verification of content failed
Unable to access these remotes: d
Try making some of these repositories available:
e6878750-3a21-4ae9-b9ae-a241f17176a4 -- [d]
failed
git-annex: get: 1 failed
```
[[!meta author=kyle]]
[[!tag projects/datalad]]

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="verifying source contents"
date="2020-09-02T15:35:18Z"
content="""
This would especially make sense when sending files to a trusted special remote, where the file may be the only copy.
Maybe, set the mtime of all files (and directories) in .git/annex/objects to some sentinel value after they're written, then check if the mtime still has that value before sending the file elsewhere?
If a special remote [[supports named pipes|todo/let_external_remotes_declare_support_for_named_pipes]], the verification could be done on-the-fly as the file is streamed to the remote.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 7"
date="2020-09-01T20:49:59Z"
content="""
Awesome, Thank you! I [still](https://git-annex.branchable.com/todo/generic_readonly_http_remote/#comment-f6e076370814fcfab3a4d203a1adf326) think that it could be named more generically than `http` (e.g. probably could remap to public `rsync://`, `ftp://` or `s3://` to which git-annex knows how to \"talk to\") even if ATM supporting only `http/https`, but I guess time will show if that would be needed.
"""]]