Merge branch 'master' of ssh://git-annex.branchable.com into master
This commit is contained in:
commit
5a9f518a42
5 changed files with 152 additions and 0 deletions
|
@ -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.
|
||||
"""]]
|
|
@ -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 :-)
|
||||
|
|
@ -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]]
|
|
@ -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.
|
||||
|
||||
|
||||
"""]]
|
|
@ -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.
|
||||
"""]]
|
Loading…
Reference in a new issue