Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
b175717811
3 changed files with 120 additions and 0 deletions
|
@ -0,0 +1,80 @@
|
|||
### Please describe the problem.
|
||||
When running `git annex testremote origin --test-readonly=filename` on a git http remote that supports git-annex, the `storeKey` test fails with error:
|
||||
|
||||
```
|
||||
storeKey: FAIL
|
||||
./Command/TestRemote.hs:277:
|
||||
(got: Left "copying to non-ssh repo not supported")
|
||||
```
|
||||
|
||||
(Full example output below)
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Using https://downloads.kitenet.net/.git/ as an example of a public repository with https git annex support:
|
||||
|
||||
```
|
||||
$ git clone https://downloads.kitenet.net/.git/
|
||||
Cloning into 'downloads.kitenet.net'...
|
||||
$ cd downloads.kitenet.net/debug-me/linux/current/
|
||||
$ git annex get debug-me-standalone-amd64.tar.gz
|
||||
get debug-me-standalone-amd64.tar.gz (from origin...)
|
||||
(checksum...) ok
|
||||
(recording state in git...)
|
||||
$ git annex testremote origin --test-readonly debug-me-standalone-amd64.tar.gz
|
||||
testremote origin Remote Tests
|
||||
unavailable remote
|
||||
removeKey: dropping from http remote not supported
|
||||
OK
|
||||
storeKey: FAIL
|
||||
./Command/TestRemote.hs:277:
|
||||
(got: Left "copying to non-ssh repo not supported")
|
||||
checkPresent: OK (0.02s)
|
||||
retrieveKeyFile: download failed: ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 6, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just "!dne!", service name: Just "443"): does not exist (Name or service not known)
|
||||
download failed: ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 6, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just "!dne!", service name: Just "443"): does not exist (Name or service not known)
|
||||
OK (0.01s)
|
||||
retrieveKeyFileCheap: OK
|
||||
key size Just 13600699; NoChunks; encryption none
|
||||
present True: OK (0.61s)
|
||||
retrieveKeyFile: OK (2.39s)
|
||||
fsck downloaded object: OK
|
||||
retrieveKeyFile resume from 33%: OK (1.95s)
|
||||
fsck downloaded object: OK
|
||||
retrieveKeyFile resume from 0: OK (1.94s)
|
||||
fsck downloaded object: OK
|
||||
retrieveKeyFile resume from end: OK (0.68s)
|
||||
fsck downloaded object: OK
|
||||
|
||||
1 out of 14 tests failed (7.61s)
|
||||
failed
|
||||
git-annex: testremote: 1 failed
|
||||
```
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
```
|
||||
git-annex version: 7.20191230-g985373f8e
|
||||
build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
|
||||
dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.2.0.1 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.10.5 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 BLAKE2BP512E BLAKE2BP512 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 git-lfs hook external
|
||||
operating system: linux x86_64
|
||||
supported repository versions: 7
|
||||
upgrade supported from repository versions: 0 1 2 3 4 5 6
|
||||
```
|
||||
|
||||
OS: Arch Linux (5.5.1-arch1-1)
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
I came across this while trying to make our hosted git and git-annex service (gin.g-node.org) open to public https git annex downloads. I was using the `testremote` command to make sure everything works as intended and saw the error thinking, at first, that the server was serving something incorrectly. The error message does clearly state that `copying to non-ssh repo not supported`, so I thought I'd try with kitenet to see if the same happens and it does.
|
||||
|
||||
I don't know if this is a bug or intentional—perhaps the test should be failing to indicate that the remote doesn't support `storeKey`? On the other hand, the `removeKey` test displays the "not supported" message and then passes, so maybe the `storeKey` test should behave the same way.
|
||||
|
||||
It's possible there's another issue here I'm not entirely aware of.
|
||||
|
||||
|
||||
### 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)
|
||||
|
||||
Of course! I use and rely on it daily :)
|
23
doc/forum/Annex_v7_repos_and_plain_git_files.mdwn
Normal file
23
doc/forum/Annex_v7_repos_and_plain_git_files.mdwn
Normal file
|
@ -0,0 +1,23 @@
|
|||
Hi,
|
||||
This is not an issue, more some questions related to my 'legacy' git-annex worklfow which is disturbed with v7 repos.
|
||||
|
||||
## The context
|
||||
I've got an old repo (initially v5) which has both plain git txt files and annexed binary files. The plain git files don't go through git-annex, only git.
|
||||
THis way, I have the classic git history of the txt files, versionning, plus the management of the (big) binaries via git-annex.
|
||||
The best of the two worlds.
|
||||
|
||||
## The pb
|
||||
I converted it to v7, and it is now not possible to add plain git files anymore though 'git add', they are managed by git-annex automatically, probably because of the smudge filter added in .git/info/attributes.
|
||||
I understand (and like) this new behaviour, because it avoids adding big binary files though 'git add' by accident. But in this repo, I would like to come back to the old behaviour.
|
||||
|
||||
## What I did
|
||||
I disabled git-annex smudge filter in the file .git/info/attributes, which is now:
|
||||
|
||||
#* filter=annex
|
||||
.* !filter
|
||||
|
||||
## Question at 100000$
|
||||
Is this safe ?
|
||||
|
||||
## Question 2
|
||||
Is there an other way of achieving this (adding plain git files outside git-annex) ?
|
|
@ -0,0 +1,17 @@
|
|||
[[!comment format=mdwn
|
||||
username="chkno@50332f55d5ef2f4b7c6bec5253b853a8f2dc770e"
|
||||
nickname="chkno"
|
||||
avatar="http://cdn.libravatar.org/avatar/8194377c81da838dda761a5d93b9c25c"
|
||||
subject="Three union-mounting methods that *don't* work"
|
||||
date="2020-02-08T06:21:03Z"
|
||||
content="""
|
||||
Linux's in-tree union-mounting option overlayfs [does not support modifications to underlying filesystems while an overlayfs mount is active](https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt):
|
||||
|
||||
> Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.
|
||||
|
||||
I.e., it's great for the LiveCD case of combining a read-only squashfs and a private tmpfs into something that behaves just like a normal filesystem, but it cannot be used to export a read-only view of multiple mutable resources.
|
||||
|
||||
I can report that [aufs](http://aufs.sourceforge.net/) also doesn't work for this use case, at least as of 2014 when I last tried it. Writes to underlying filesystems cause kernel panics that bring the whole machine down.
|
||||
|
||||
I can also report that [hanwen/go-fuse's unionfs](https://github.com/hanwen/go-fuse/blob/master/example/unionfs/main.go) doesn't work for this use case. Example problem: Growing files' sizes get stuck at the size they were the first time they were viewed through the union mount.
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue