remove old closed bugs and todo items to speed up wiki updates and reduce size
Remove closed bugs and todos that were last edited or commented before 2021.
Except for ones tagged projects/* since projects like datalad want to keep
around records of old deleted bugs longer.
Command line used:
for f in $(grep -l '|done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2021 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2021 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done
for f in $(grep -l '\[\[done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2021 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2021 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done
This commit is contained in:
Joey Hess
parent
a9db0a5055
commit
28921af543
566 changed files with 0 additions and 15810 deletions
|
|
@ -1,15 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
The metadata doesn't include the day for RSS feeds, which is probably only a problem for me as I've built something on top of the metadata to provide an interface for selecting podcasts.
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
The attached patch adds the day field to the metadata.
|
||||
|
||||
There's also a tiny bit extra for stack.yaml which will only affect people who have nix enabled in Stack and will make the build successful for those people.
|
||||
|
||||
### 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)
|
||||
|
||||
git-annex is awesome, I lean on it heavily nearly every single day.
|
||||
|
||||
> [[merged|done]]. Thanks for the patch! --[[Joey]]
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="seantparsons"
|
||||
avatar="http://cdn.libravatar.org/avatar/616fb81847630239dd1ab099138cb685"
|
||||
subject="Since the attachment doesn't appear to be there, here's the content."
|
||||
date="2017-10-22T20:32:21Z"
|
||||
content="""
|
||||
diff --git a/Annex/MetaData.hs b/Annex/MetaData.hs
|
||||
index e22ed05a6..355c5124a 100644
|
||||
--- a/Annex/MetaData.hs
|
||||
+++ b/Annex/MetaData.hs
|
||||
@@ -60,10 +60,11 @@ dateMetaData :: UTCTime -> MetaData -> MetaData
|
||||
dateMetaData mtime old = MetaData $ M.fromList $ filter isnew
|
||||
[ (yearMetaField, S.singleton $ toMetaValue $ show y)
|
||||
, (monthMetaField, S.singleton $ toMetaValue $ show m)
|
||||
+ , (dayMetaField, S.singleton $ toMetaValue $ show d)
|
||||
]
|
||||
where
|
||||
isnew (f, _) = S.null (currentMetaDataValues f old)
|
||||
- (y, m, _d) = toGregorian $ utctDay mtime
|
||||
+ (y, m, d) = toGregorian $ utctDay mtime
|
||||
|
||||
{- Parses field=value, field+=value, field-=value, field?=value -}
|
||||
parseModMeta :: String -> Either String ModMeta
|
||||
diff --git a/Annex/MetaData/StandardFields.hs b/Annex/MetaData/StandardFields.hs
|
||||
index c91b53930..b9ea47e2f 100644
|
||||
--- a/Annex/MetaData/StandardFields.hs
|
||||
+++ b/Annex/MetaData/StandardFields.hs
|
||||
@@ -9,6 +9,7 @@ module Annex.MetaData.StandardFields (
|
||||
tagMetaField,
|
||||
yearMetaField,
|
||||
monthMetaField,
|
||||
+ dayMetaField,
|
||||
lastChangedField,
|
||||
mkLastChangedField,
|
||||
isLastChangedField
|
||||
@@ -27,6 +28,9 @@ yearMetaField = mkMetaFieldUnchecked \"year\"
|
||||
monthMetaField :: MetaField
|
||||
monthMetaField = mkMetaFieldUnchecked \"month\"
|
||||
|
||||
+dayMetaField :: MetaField
|
||||
+dayMetaField = mkMetaFieldUnchecked \"day\"
|
||||
+
|
||||
lastChangedField :: MetaField
|
||||
lastChangedField = mkMetaFieldUnchecked lastchanged
|
||||
|
||||
diff --git a/stack.yaml b/stack.yaml
|
||||
index d84c4682e..ac601200e 100644
|
||||
--- a/stack.yaml
|
||||
+++ b/stack.yaml
|
||||
@@ -24,3 +24,11 @@ extra-deps:
|
||||
explicit-setup-deps:
|
||||
git-annex: true
|
||||
resolver: lts-9.9
|
||||
+nix:
|
||||
+ packages:
|
||||
+ - ncurses
|
||||
+ - icu
|
||||
+ - libcxx
|
||||
+ - gcc
|
||||
+ - zlib
|
||||
+ - rsync
|
||||
\ No newline at end of file
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2017-11-08T18:51:20Z"
|
||||
content="""
|
||||
Unfortunately the added nix section broke the i386-ancient build,
|
||||
which uses stack 1.0.4. That version of stack complains:
|
||||
|
||||
Executable named nix-shell not found on path: ["/usr/local/sbin","/usr/local/bin","/sbin","/bin","/usr/sbin","/usr/bin"]
|
||||
|
||||
So, I've reverted the addition of that section.
|
||||
"""]]
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
I'm running into an issue where adding files to a git annex repository fails when I specify a number of jobs equal to the number of cores on my machine, resulting in the following message:
|
||||
|
||||
`git-annex: getCurrentDirectory:getWorkingDirectory: resource exhausted (Too many open files)`
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Running the command below on a directory with less than 1000 files.
|
||||
|
||||
```
|
||||
git init
|
||||
git annex init
|
||||
git annex add --jobs 16 .
|
||||
```
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
Mac OSX 10.15.5
|
||||
|
||||
```
|
||||
# brew install git-annex
|
||||
20:16 $ git annex version
|
||||
git-annex version: 8.20200617
|
||||
build flags: Assistant Webapp Pairing S3 WebDAV FsEvents TorrentParser MagicMime Feeds Testsuite
|
||||
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.6.5 http-client-0.7.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0.1
|
||||
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: darwin x86_64
|
||||
supported repository versions: 8
|
||||
upgrade supported from repository versions: 0 1 2 3 4 5 6 7
|
||||
local repository version: 8
|
||||
```
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
The log was empty, but here is a snippet of the stdout.
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
|
||||
add test-app/test/app.R
|
||||
git-annex: getCurrentDirectory:getWorkingDirectory: resource exhausted (Too many open files)
|
||||
failed
|
||||
add tool_args/d1b89bbf441df390a60d787af813817579d2b760
|
||||
git-annex: getCurrentDirectory:getWorkingDirectory: resource exhausted (Too many open files)
|
||||
failed
|
||||
...
|
||||
add CCLE_expression_full.csv
|
||||
git-annex: cp: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)
|
||||
failed
|
||||
add Achilles_20Q1/CCLE_expression_full.csv
|
||||
git-annex: cp: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)
|
||||
failed
|
||||
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### 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 been having quite a bit of fun revisiting git-annex and datalad after quite a while, and I'm really excited to see how far things have come. I'm pretty close to adopting these tools in my data science group after a pretty exhaustive search of related technologies like quilt, dvc, and attempts to role my own solution. Using Github + the S3 special remote w/versioning enabled is just about the best solution to dataset tracking I've come across.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-07-21T14:09:48Z"
|
||||
content="""
|
||||
It looks to me like git-annex add is leaking a FD to
|
||||
.git/annex/othertmp.lck
|
||||
|
||||
I ran git-annex add -J16 in a repo with 1000 files, and around half way
|
||||
through it had 832 open FDs, and 737 of them were that lock file. 55 more
|
||||
were pipes (to and from git cat-file etc; recent work reduced the number of
|
||||
those a lot), and the remaining 37 were event and timer stuff used by the
|
||||
RTS.
|
||||
|
||||
The number of -J does not change that leak, same number with -J2. -J2 will
|
||||
open slightly less other files though. Without -J, the FD leak does not
|
||||
happen.
|
||||
|
||||
Also, git-annex 8.20200330 does not have this problem, it seems to be a
|
||||
recent bug.
|
||||
|
||||
[[!commit 3334130368829ad2041006560e578f1f876f68e4]] claimed to fix a leak
|
||||
in this same code path.
|
||||
"""]]
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""analysis"""
|
||||
date="2020-07-21T18:35:08Z"
|
||||
content="""
|
||||
Utility.LockPool.STM.releaseLock seems to be where the problem is.
|
||||
|
||||
It waits to close a lock FD if some other thread is using the lock.
|
||||
But, this means that, if enough threads are run that the lock is
|
||||
always in use by one thread, it will never close it. Meanwhile, each
|
||||
lockShared call opens the lock file anew, accumilating another FD.
|
||||
|
||||
3334130368829ad2041006560e578f1f876f68e4 is at fault, indeed.
|
||||
|
||||
That commit mentions that it would be better to have two calls to
|
||||
lockShared only open the file once, but that it would be difficult to do
|
||||
that atomically. Perhaps there is a way to do that... It didn't seem easy
|
||||
to do this time either.
|
||||
|
||||
Alternatively, registerCloseLockFile currently takes an action that closes
|
||||
one lock FD, and just combines that to its existing close action with `>>`.
|
||||
So it builds up one big action that closes all the FDs. Instead, make each
|
||||
lock handle contain its close action, and have releaseLock only release the
|
||||
one it was called with. Implemented this, and it solved it.
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="nicholsn"
|
||||
nickname="nolan.nichols"
|
||||
avatar="http://cdn.libravatar.org/avatar/12e81148e905851b4794288e8bf336e9"
|
||||
subject="Thank you"
|
||||
date="2020-07-28T03:57:32Z"
|
||||
content="""
|
||||
This fix is much appreciated!
|
||||
"""]]
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Trying to build git-annex on Windows by running "stack build" as instructed by https://git-annex.branchable.com/install/Windows/ currently fails with the following error:
|
||||
|
||||
[[!format sh """
|
||||
|
||||
[305 of 636] Compiling Annex.PidLock
|
||||
|
||||
Annex\PidLock.hs:70:9: error:
|
||||
* Couldn't match expected type `Annex a' with actual type `IO a'
|
||||
* In a stmt of a 'do' block: gonopidlock
|
||||
In the expression:
|
||||
do let p = f (proc cmd ps)
|
||||
let gonopidlock = withCreateProcess p a
|
||||
gonopidlock
|
||||
In an equation for `pidLockChildProcess':
|
||||
pidLockChildProcess cmd ps f a
|
||||
= do let p = ...
|
||||
let gonopidlock = ...
|
||||
gonopidlock
|
||||
* Relevant bindings include
|
||||
gonopidlock :: IO a (bound at Annex\PidLock.hs:47:13)
|
||||
a :: Maybe Handle
|
||||
-> Maybe Handle -> Maybe Handle -> ProcessHandle -> IO a
|
||||
(bound at Annex\PidLock.hs:45:30)
|
||||
pidLockChildProcess :: FilePath
|
||||
-> [String]
|
||||
-> (CreateProcess -> CreateProcess)
|
||||
-> (Maybe Handle
|
||||
-> Maybe Handle -> Maybe Handle -> ProcessHandle -> IO a)
|
||||
-> Annex a
|
||||
(bound at Annex\PidLock.hs:45:1)
|
||||
|
|
||||
70 | gonopidlock
|
||||
| ^^^^^^^^^^^
|
||||
|
||||
"""]]
|
||||
|
||||
This happens when trying to build both the most recent commit (20c7e6c) and the most recent tag (8.20200908).
|
||||
|
||||
- stack version: 2.3.3
|
||||
- Windows version: Windows 7 Enterprise, version 6.1
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-10-07T16:03:04Z"
|
||||
content="""
|
||||
Thanks for reporting this. I usually only find out when the Windows CI
|
||||
fails, but it's not been running for a while.
|
||||
|
||||
I've fixed this particular problem, but don't have a windows build env
|
||||
handy to test the rest of the build. Please followup if there's a
|
||||
subsequent build failure.
|
||||
"""]]
|
||||
|
|
@ -1,149 +0,0 @@
|
|||
### Please describe the problem.
|
||||
git-annex failed to build with latest tasty 1.3
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
Build git-annex with tasty-1.3
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
8.20200501 on Arch Linux.
|
||||
|
||||
### Please provide any additional information below.
|
||||
[545 of 638] Compiling Test ( Test.hs, dist/build/git-annex/git-annex-tmp/Test.dyn_o )
|
||||
|
||||
Test.hs:98:13: error:
|
||||
• Couldn't match type ‘(,) [String]’ with ‘Parser’
|
||||
Expected type: Parser TestOptions
|
||||
Actual type: ([String], TestOptions)
|
||||
• In the expression:
|
||||
TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")
|
||||
<*> switch (long "fakessh" <> internal)
|
||||
<*> cmdParams "non-options are for internal use only"
|
||||
In an equation for ‘optParser’:
|
||||
optParser
|
||||
= TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")
|
||||
<*> switch (long "fakessh" <> internal)
|
||||
<*> cmdParams "non-options are for internal use only"
|
||||
|
|
||||
98 | optParser = TestOptions
|
||||
| ^^^^^^^^^^^...
|
||||
|
||||
Test.hs:99:13: error:
|
||||
• Couldn't match type ‘Parser Test.Tasty.Options.OptionSet’
|
||||
with ‘Test.Tasty.Options.OptionSet’
|
||||
Expected type: ([String], Test.Tasty.Options.OptionSet)
|
||||
Actual type: ([String], Parser Test.Tasty.Options.OptionSet)
|
||||
• In the second argument of ‘(<$>)’, namely
|
||||
‘suiteOptionParser ingredients (tests False True mempty)’
|
||||
In the first argument of ‘(<*>)’, namely
|
||||
‘TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)’
|
||||
In the first argument of ‘(<*>)’, namely
|
||||
‘TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")’
|
||||
|
|
||||
99 | <$> suiteOptionParser ingredients (tests False True mempty)
|
||||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Test.hs:100:13: error:
|
||||
• Couldn't match type ‘Parser’ with ‘(,) [String]’
|
||||
Expected type: ([String], Bool)
|
||||
Actual type: Parser Bool
|
||||
• In the second argument of ‘(<*>)’, namely
|
||||
‘switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")’
|
||||
In the first argument of ‘(<*>)’, namely
|
||||
‘TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")’
|
||||
In the first argument of ‘(<*>)’, namely
|
||||
‘TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")
|
||||
<*> switch (long "fakessh" <> internal)’
|
||||
|
|
||||
100 | <*> switch
|
||||
| ^^^^^^...
|
||||
|
||||
Test.hs:104:13: error:
|
||||
• Couldn't match type ‘Parser’ with ‘(,) [String]’
|
||||
Expected type: ([String], Bool)
|
||||
Actual type: Parser Bool
|
||||
• In the second argument of ‘(<*>)’, namely
|
||||
‘switch (long "fakessh" <> internal)’
|
||||
In the first argument of ‘(<*>)’, namely
|
||||
‘TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")
|
||||
<*> switch (long "fakessh" <> internal)’
|
||||
In the expression:
|
||||
TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")
|
||||
<*> switch (long "fakessh" <> internal)
|
||||
<*> cmdParams "non-options are for internal use only"
|
||||
|
|
||||
104 | <*> switch
|
||||
| ^^^^^^...
|
||||
|
||||
Test.hs:108:13: error:
|
||||
• Couldn't match type ‘Parser’ with ‘(,) [String]’
|
||||
Expected type: ([String], Types.Command.CmdParams)
|
||||
Actual type: Parser Types.Command.CmdParams
|
||||
• In the second argument of ‘(<*>)’, namely
|
||||
‘cmdParams "non-options are for internal use only"’
|
||||
In the expression:
|
||||
TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")
|
||||
<*> switch (long "fakessh" <> internal)
|
||||
<*> cmdParams "non-options are for internal use only"
|
||||
In an equation for ‘optParser’:
|
||||
optParser
|
||||
= TestOptions
|
||||
<$> suiteOptionParser ingredients (tests False True mempty)
|
||||
<*>
|
||||
switch
|
||||
(long "keep-failures"
|
||||
<> help "preserve repositories on test failure")
|
||||
<*> switch (long "fakessh" <> internal)
|
||||
<*> cmdParams "non-options are for internal use only"
|
||||
|
|
||||
108 | <*> cmdParams "non-options are for internal use only"
|
||||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
|
||||
### 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)
|
||||
Yes.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
### Please describe the problem.
|
||||
Historically (in older versions of MacOS) to get git-annex working with SourceTree I've done the following:
|
||||
|
||||
When committing in SourceTree or SmartGit after adding annex, you may get error "git: 'annex' is not a git command". To fix:
|
||||
First make sure your client is using the system git
|
||||
In SourceTree preferences, go to Git tab and use system git (likely in /usr/bin/git)
|
||||
Disable SIP (needed step starting from Mac OSX El Capitan), by doing the following:
|
||||
Restart your Mac.
|
||||
Then, make a symbolic link so SourceTree/SmartGit can see git-annex (look at which git-annex to find real location):
|
||||
sudo ln -s /usr/local/bin/git-annex /usr/bin/git-annex
|
||||
Re-enable SIP, by following the same steps for disabling, but rather issuing the command csrutil enable in the Terminal window
|
||||
|
||||
But now, I still can't write the symbolic link with SIP disabled. Obviously this isn't git-annex's fault. But I cannot figure out how to integrate git-annex so that SourceTree can work with it.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
See above.
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
git-annex version: 8.20200908
|
||||
macOS 10.15.6
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### 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)
|
||||
|
||||
|
||||
> [[notabug|done]] --[[Joey]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="mark@6b90344cdab3158eacb94a3944460d138afc9bef"
|
||||
nickname="mark"
|
||||
avatar="http://cdn.libravatar.org/avatar/780625d9a11f1840abd94822dfe3e9f5"
|
||||
subject="comment 1"
|
||||
date="2020-09-28T21:10:56Z"
|
||||
content="""
|
||||
And BTW, we really value git-annex and use it for keeping all of our golden reference outputs for regression testing in place and available for others who need to run tests.
|
||||
"""]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="mark@6b90344cdab3158eacb94a3944460d138afc9bef"
|
||||
nickname="mark"
|
||||
avatar="http://cdn.libravatar.org/avatar/780625d9a11f1840abd94822dfe3e9f5"
|
||||
subject="comment 2"
|
||||
date="2020-09-28T21:40:21Z"
|
||||
content="""
|
||||
Switching SourceTree to look at /usr/local/git/bin fixed the problem.
|
||||
|
||||
This can be CLOSED.
|
||||
"""]]
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
I'm not sure if this is a bug per se but a small bother.
|
||||
|
||||
In [deleting unwanted files](https://git-annex.branchable.com/tips/deleting_unwanted_files/) it is mentioned that you can use `git annex drop --force $file` to make it go away. But after that when fsck is run it will warn that there are no copies and that it should be marked as dead. And if it's deleted from the branch it will still complain if fsck is run with `--all`.
|
||||
|
||||
Shouldn't they be marked dead automatically if the copy count reaches 0?
|
||||
|
||||
Example:
|
||||
|
||||
[[!format sh """
|
||||
$ git annex fsck
|
||||
fsck test
|
||||
** No known copies exist of test
|
||||
failed
|
||||
(recording state in git...)
|
||||
git-annex: fsck: 1 failed
|
||||
$ rm test
|
||||
$ git annex fsck --all
|
||||
$ fsck SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054
|
||||
** No known copies exist of SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054
|
||||
|
||||
(Avoid this check by running: git annex dead --key )
|
||||
failed
|
||||
(recording state in git...)
|
||||
git-annex: fsck: 1 failed
|
||||
$ git annex forget --force
|
||||
$ git annex repair --force
|
||||
$ git annex fsck --all
|
||||
fsck SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054
|
||||
** No known copies exist of SHA256E-s16--c21f3ac6b5f6e45b1c0b292bcd5cc806298ecb033bc7030a6071e3c894d73054
|
||||
|
||||
(Avoid this check by running: git annex dead --key )
|
||||
failed
|
||||
(recording state in git...)
|
||||
git-annex: fsck: 1 failed
|
||||
"""]]
|
||||
|
||||
From this, not even forget,fsck or repair can make this go away but only `git annex dead --key` which can be a pain to call it on a ton of different keys (there doesn't appear to be an option to batch mark them all as dead either).
|
||||
|
||||
|
||||
|
||||
|
||||
Additionally the key will still remain in the `git-annex` branch, I'm not sure about the internal optimizations in place but I'd assume leaving unused keys around in the branch can cause slowdowns when it's checked out/updated in repositories with a lot of add/update/delete activity.
|
||||
|
||||
|
||||
### 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'm using git annex to manage all my personal data, thanks for making such an amazing piece of software :)
|
||||
|
||||
> [[notabug|done]] --[[Joey]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="CandyAngel"
|
||||
avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
|
||||
subject="comment 1"
|
||||
date="2018-10-03T08:01:25Z"
|
||||
content="""
|
||||
Regarding git-annex-dead:
|
||||
|
||||
> This command exists to deal with situations where data has been lost, and **you know it has**, and you want to stop being reminded of that fact.
|
||||
|
||||
Dead-ifying keys automatically could result in the situation where a key is marked as dead and the user doesn't (and wouldn't) know about it (until trying to use the file) because git-annex would never complain about it.
|
||||
|
||||
Adding --batch support for `git-annex-dead --keys` would be good. I suggest making a todo for just that and/or for adding support for `git annex drop --force --dead`?
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2018-10-04T17:03:42Z"
|
||||
content="""
|
||||
I agree with CandyAngel, this is not something that should be done
|
||||
automatically.
|
||||
|
||||
While `git annex dead --batch` could be worth adding, it might be more
|
||||
useful to support `git annex dead --files file|dir ...` so you can just run
|
||||
it on the same files you're dropping.
|
||||
"""]]
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="glasserc"
|
||||
avatar="http://cdn.libravatar.org/avatar/8e865c04033751520601e9c15e58ddc4"
|
||||
subject="Is `dead` really the solution here?"
|
||||
date="2020-05-06T20:29:03Z"
|
||||
content="""
|
||||
I encountered this behavior as well on an annex where I had decided to move a file into a different, unrelated repository. I used `dropunused` to get rid of the contents. Now I have a repository for which `git annex get` constantly complains that a file is not known to be in any repository.
|
||||
|
||||
As a naive user, I wouldn't have considered \"dead\" to be the description for this file. It isn't lost in any way, just untracked in the context of this repository. It's a bit surprising that once a file is ever tracked, it can never be untracked by any means -- even marking it as dead is still tracking the deadness of the file.
|
||||
|
||||
I guess from a theoretical point of view that some branch or some repo somewhere might still refer to the file in some way and its absence might therefore have consequences later on. From a practical point of view, once the commit removing the last link to the file is on master on all known repositories, it seems like we can consider this file \"deleted\" in a way that is distinct from \"dead\".
|
||||
|
||||
Leaving aside what the status is called, how about detecting it automatically on `dropunused`? This is a bit different from detecting it on `drop` because we have already concluded that the file is \"gone\" in some way.
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2020-05-07T15:56:38Z"
|
||||
content="""
|
||||
`git annex get` will only complain about files that are still in the
|
||||
current branch. If you want to use `--all` though, you will have to mark
|
||||
such files as dead. git-annex otherwise has no way to differentiate between
|
||||
the last copy of a file being lost inaverdently and intentionally removed.
|
||||
|
||||
Auto-deading files would hide problems.
|
||||
|
||||
> even marking it as dead is still tracking the deadness of the file
|
||||
|
||||
You can use git-annex forget to prune that information from the git-annex
|
||||
branch, but it's completely reasonable for a git repository to retain
|
||||
history by default.
|
||||
|
||||
> Leaving aside what the status is called, how about detecting it
|
||||
> automatically on `dropunused`
|
||||
|
||||
Unused files are only unused in the head of branches, not in all the
|
||||
history of the git repository. Again, git is all about preserving the
|
||||
history of files.
|
||||
"""]]
|
||||
|
|
@ -1,198 +0,0 @@
|
|||
### Please describe the problem.
|
||||
Build failure with hinotify,0.3.10 / fsnotify,0.2.1.2
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
git-annex 6.20180427 on Arch x86_64.
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
[124 of 594] Compiling Utility.DirWatcher.INotify ( Utility/DirWatcher/INotify.hs, dist/build/git-annex/git-annex-tmp/Utility/DirWatcher/INotify.dyn_o )
|
||||
|
||||
Utility/DirWatcher/INotify.hs:58:54: error:
|
||||
• Couldn't match type ‘[Char]’
|
||||
with ‘Data.ByteString.Internal.ByteString’
|
||||
Expected type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
Actual type: FilePath
|
||||
• In the third argument of ‘addWatch’, namely ‘dir’
|
||||
In the first argument of ‘void’, namely
|
||||
‘(addWatch i watchevents dir handler)’
|
||||
In the first argument of ‘catchIO’, namely
|
||||
‘void (addWatch i watchevents dir handler)’
|
||||
|
|
||||
58 | void (addWatch i watchevents dir handler)
|
||||
| ^^^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:97:41: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the first argument of ‘indir’, namely ‘f’
|
||||
In the second argument of ‘($)’, namely ‘indir f’
|
||||
In the expression: recurse $ indir f
|
||||
|
|
||||
97 | | isd = recurse $ indir f
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:99:41: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the first argument of ‘getstatus’, namely ‘f’
|
||||
In a stmt of a 'do' block: ms <- getstatus f
|
||||
In the expression:
|
||||
do ms <- getstatus f
|
||||
case ms of
|
||||
Just s
|
||||
| isSymbolicLink s
|
||||
-> when (hashook addSymlinkHook) $ runhook addSymlinkHook f ms
|
||||
| isRegularFile s -> when (hashook addHook) $ runhook addHook f ms
|
||||
_ -> noop
|
||||
|
|
||||
99 | ms <- getstatus f
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:104:80: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘runhook’, namely ‘f’
|
||||
In the second argument of ‘($)’, namely
|
||||
‘runhook addSymlinkHook f ms’
|
||||
In the expression:
|
||||
when (hashook addSymlinkHook) $ runhook addSymlinkHook f ms
|
||||
|
|
||||
104 | runhook addSymlinkHook f ms
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:107:73: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘runhook’, namely ‘f’
|
||||
In the second argument of ‘($)’, namely ‘runhook addHook f ms’
|
||||
In the expression: when (hashook addHook) $ runhook addHook f ms
|
||||
|
|
||||
107 | runhook addHook f ms
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:112:67: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the third argument of ‘checkfiletype’, namely ‘f’
|
||||
In the expression: checkfiletype isRegularFile addHook f
|
||||
In an equation for ‘go’:
|
||||
go (Closed {isDirectory = False, maybeFilePath = Just f})
|
||||
= checkfiletype isRegularFile addHook f
|
||||
|
|
||||
112 | checkfiletype Files.isRegularFile addHook f
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:115:46: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the first argument of ‘scan’, namely ‘f’
|
||||
In the expression: scan f
|
||||
In an equation for ‘go’: go (MovedIn {filePath = f}) = scan f
|
||||
|
|
||||
115 | go (MovedIn { filePath = f }) = scan f
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:117:44: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘runhook’, namely ‘f’
|
||||
In the expression: runhook delDirHook f Nothing
|
||||
In an equation for ‘go’:
|
||||
go (MovedOut {isDirectory = isd, filePath = f})
|
||||
| isd = runhook delDirHook f Nothing
|
||||
| otherwise = runhook delHook f Nothing
|
||||
|
|
||||
117 | | isd = runhook delDirHook f Nothing
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:118:47: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘runhook’, namely ‘f’
|
||||
In the expression: runhook delHook f Nothing
|
||||
In an equation for ‘go’:
|
||||
go (MovedOut {isDirectory = isd, filePath = f})
|
||||
| isd = runhook delDirHook f Nothing
|
||||
| otherwise = runhook delHook f Nothing
|
||||
|
|
||||
118 | | otherwise = runhook delHook f Nothing
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:124:54: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘runhook’, namely ‘f’
|
||||
In the second argument of ‘($)’, namely
|
||||
‘runhook delDirHook f Nothing’
|
||||
In the expression: guarded $ runhook delDirHook f Nothing
|
||||
|
|
||||
124 | | isd = guarded $ runhook delDirHook f Nothing
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:125:57: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘runhook’, namely ‘f’
|
||||
In the second argument of ‘($)’, namely ‘runhook delHook f Nothing’
|
||||
In the expression: guarded $ runhook delHook f Nothing
|
||||
|
|
||||
125 | | otherwise = guarded $ runhook delHook f Nothing
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:127:58: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘filetype’, namely ‘f’
|
||||
In the first argument of ‘unlessM’, namely
|
||||
‘(filetype (const True) f)’
|
||||
In the expression: unlessM (filetype (const True) f)
|
||||
|
|
||||
127 | guarded = unlessM (filetype (const True) f)
|
||||
| ^
|
||||
|
||||
Utility/DirWatcher/INotify.hs:130:50: error:
|
||||
• Couldn't match type ‘Data.ByteString.Internal.ByteString’
|
||||
with ‘[Char]’
|
||||
Expected type: FilePath
|
||||
Actual type: System.Posix.ByteString.FilePath.RawFilePath
|
||||
• In the second argument of ‘runhook’, namely ‘f’
|
||||
In the expression: runhook modifyHook f Nothing
|
||||
In an equation for ‘go’:
|
||||
go (Modified {isDirectory = isd, maybeFilePath = Just f})
|
||||
| isd = noop
|
||||
| otherwise = runhook modifyHook f Nothing
|
||||
|
|
||||
130 | | otherwise = runhook modifyHook f Nothing
|
||||
| ^
|
||||
|
||||
"""]]
|
||||
|
||||
### 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)
|
||||
|
||||
Yes!
|
||||
|
||||
> [[fixed|done]] a long time ago --[[Joey]]
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
### Please describe the problem.
|
||||
I get error while attempting to create an adb special remote
|
||||
Problem appears to be with gvfs (mtp) mount point that my phone is getting mounted to.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
Attach android phone to computer via USB. (eg Pixel3A, Samsung Galaxy S6 etc.)
|
||||
Phone mounts using gvfs-mtp. (GNOME virt file system)
|
||||
Specifically in my case at the following path:
|
||||
|
||||
/run/user/1000/gvfs/mtp\:host\=Google_Pixel_3a_94MBYKEOEJS/Internal\ shared\ storage/DCIM
|
||||
|
||||
Attempt to create adb special remote as follows:
|
||||
|
||||
git annex initremote android type=adb
|
||||
androiddirectory=/run/user/1000/gvfs/mtp\:host\=Google_Pixel_3a_94MBYKEOEJS/Internal\ shared\ storage/DCIM
|
||||
encryption=none exporttree=yes importtree=yes
|
||||
|
||||
Results in following error message:
|
||||
initremote android git-annex: adb: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory) failed git-annex: initremote: 1 failed
|
||||
|
||||
I can successfully 'cd' into the path via xterm and browse the phone's DCIM directory etc as normal
|
||||
so the path itself if fine. I also tried enclosing the dir name in quotes, double quotes etc but that didn't help
|
||||
Also tried by creating a symbolic link to the path name and specifying the link name, but no joy
|
||||
I was hoping that it was the ":" between mtp and host that was the issue)
|
||||
|
||||
I have also attempted just to use the directory special remote as well - but I get same error.
|
||||
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
8.20200226 (but I have also seen same issue on earlier ver 7)
|
||||
I upgraded to 8 in hope of rectifying the issue.
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
Running Debian 10.3
|
||||
|
||||
|
||||
### Have you had any luck using git-annex before?
|
||||
Yes, have been using git-annex successfully for several years, but this is my first attempt at using the adb special remote.
|
||||
|
||||
Thanks
|
||||
M.
|
||||
|
||||
|
||||
> [[notabug|done]]
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-04-02T00:36:55Z"
|
||||
content="""
|
||||
Your phone is being mounted with mtp. That is not the protocol used by the
|
||||
adb special remote.
|
||||
|
||||
The androiddirectory parameter cannot be used to specify a path on
|
||||
your local computer. I think the documentation of that parameter is clear
|
||||
about that?
|
||||
|
||||
You seem to not have the adb command installed, based on the error message.
|
||||
If you install it and follow the documentation, I'd expect it will work.
|
||||
|
||||
Or, since the phone is already getting mounted by mtp, you can, instead of
|
||||
making an adb special remote, simply make a
|
||||
[directory special remote](https://git-annex.branchable.com/special_remotes/directory/)
|
||||
"""]]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Running "git clone git://git-annex.branchable.com/" in git-bash on Windows 7 fails with:
|
||||
|
||||
[[!format sh """
|
||||
error: invalid path 'doc/bugs/Add_day_to_metadata./comment_1_d46d9f085b7077cc95d71628e45c231d._comment'
|
||||
fatal: unable to checkout working tree
|
||||
warning: Clone succeeded, but checkout failed.
|
||||
You can inspect what was checked out with 'git status'
|
||||
and retry with 'git restore --source=HEAD :/'
|
||||
"""]
|
||||
|
||||
I believe the failure is because "Add_day_to_metadata." (a path component with an empty extension) is invalid on Windows.
|
||||
|
||||
Because of this, developing and building on Windows is harder and more needlessly complicated than it should be. Please rename the "doc/bugs/Add_day_to_metadata." directory along with the other directories whose names also end in a period (They can be found with "git ls-tree -r --name-only HEAD | grep '\./'").
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Cloning the git-annex repository on Windows 7 — or any other Windows, I believe.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-10-07T16:11:23Z"
|
||||
content="""
|
||||
Thanks for reporting that. We used to have problems with : getting into
|
||||
filenames in the website, fixed that, so I've gone ahead and fixed this
|
||||
too, including (I hope) configuring it to reject a trailing period.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="jwodder"
|
||||
avatar="http://cdn.libravatar.org/avatar/b06e01332c949b895c681cc92934f36a"
|
||||
subject="comment 2"
|
||||
date="2020-10-08T12:44:51Z"
|
||||
content="""
|
||||
You overlooked the directory `doc/bugs/Very_not_graceful_exit_on_cwd_deletion_while_git_annex_adding_files.`
|
||||
"""]]
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2020-10-22T17:57:49Z"
|
||||
content="""
|
||||
So I did, fixed now.
|
||||
"""]]
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="jwodder"
|
||||
avatar="http://cdn.libravatar.org/avatar/b06e01332c949b895c681cc92934f36a"
|
||||
subject="comment 4"
|
||||
date="2020-10-22T18:13:40Z"
|
||||
content="""
|
||||
Unfortunately, it turns out that empty extensions aren't the only problem. Trying to check out the latest commit (577af1b) on Windows 7 now gives:
|
||||
|
||||
```
|
||||
error: unable to create file doc/bugs/__34__git_submodule_foreach_git_annex_init__34___fails_with___34__git__58___createProcess__58___runInteractiveProcess__58___chdir__58___inappropriate_type___40__Not_a_directory__41____34__/comment_1_8a6cd8dc6e7c2cdefd60a07356be1d27._comment: Filename too long
|
||||
error: unable to create file doc/bugs/__34__git_submodule_foreach_git_annex_init__34___fails_with___34__git__58___createProcess__58___runInteractiveProcess__58___chdir__58___inappropriate_type___40__Not_a_directory__41____34__/comment_3_fd3a287ee6e73946889a4dd406fae0fc._comment: Filename too long
|
||||
error: unable to create file doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_returned_ErrorIO_while_attempting_to_perform_prepare___34__PRAGMA_journal__95__mode__61__WAL__59____34____58___disk_I__47__O_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment: Filename too long
|
||||
error: unable to create file doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_returned_ErrorIO_while_attempting_to_perform_prepare___34__PRAGMA_journal__95__mode__61__WAL__59____34____58___disk_I__47__O_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment: Filename too long
|
||||
error: unable to create file doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_returned_ErrorIO_while_attempting_to_perform_prepare___34__PRAGMA_journal__95__mode__61__WAL__59____34____58___disk_I__47__O_error/comment_3_b49a3df3b13f564e588824910a07bc43._comment: Filename too long
|
||||
error: unable to create file doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_returned_ErrorIO_while_attempting_to_perform_prepare___34__PRAGMA_journal__95__mode__61__WAL__59____34____58___disk_I__47__O_error/comment_4_a9e6e37dbaa1664d825bdbd64de4fbdd._comment: Filename too long
|
||||
```
|
||||
"""]]
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 5"""
|
||||
date="2020-11-02T17:38:34Z"
|
||||
content="""
|
||||
I think windows has a limit of around 256 characters on the total length of
|
||||
a path. (vs 4096 on linux)
|
||||
|
||||
So, even if ikiwiki had a way to limit the length of a page name,
|
||||
which could perhaps be done with `wiki_file_regexp`, that would not help,
|
||||
because several short page names can be nested into a path that ends up too
|
||||
long for windows. As is the case here; neither of the bug report filenames
|
||||
is too long, only the comments on them end up too long. Allowing posting a
|
||||
bug report but not commenting on it would not be good.
|
||||
|
||||
Since I am flatly NOT going to decouple the bug tracking repo from the
|
||||
source code repo, this seems to put me in the position of going around
|
||||
cleaning up things that happen to be too long for windows manually. Which I
|
||||
frankly, also do not want to do. I guess I'll take patches if people want
|
||||
to send them, but is this really how we want to spend our time?
|
||||
|
||||
(Also, renaming someone's bug report out from under where it was risks them
|
||||
not seeing a request for more information.)
|
||||
|
||||
Note that, windows provides ways to avoid these length limits, by prefixing
|
||||
paths with a sequence that avoids using a compatability layer that imposes
|
||||
them, and instead uses a more modern layer that has more reasonable limits.
|
||||
I think git-annex actually uses that itself, thanks to some improvements to
|
||||
ghc. git for windows could be made to also, I suppose.
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 6"""
|
||||
date="2020-11-02T19:17:01Z"
|
||||
content="""
|
||||
Hmm, the form has size=40, but people are pasting entire long error
|
||||
messages into it. Although special characters also being escaped increases
|
||||
the length, if it were really limited to around that length, it would still
|
||||
be short enough.
|
||||
|
||||
Ok, added maxlength=50 to it.
|
||||
"""]]
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Trying to replace my rrsync setup with a restricted git-annex-shell, I ran into the following problem (slightly obfuscated):
|
||||
|
||||
± git annex get .
|
||||
get secret (from secrets...)
|
||||
git-annex-shell: Only allowed to access ~/store not ~/store/secrets/6a8/d0c/GPGHMACSHA1--0000000000000000000000000000000000000000/GPGHMACSHA1--0000000000000000000000000000000000000000
|
||||
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
|
||||
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [Receiver=3.1.2]
|
||||
|
||||
It does not matter if GIT_ANNEX_SHELL_DIRECTORY is just "store", "store/secrets" or the full absolute path to any of the two directories, the output and the results are the same.
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Create an encrypted rsync remote in ~/store/secrets, add
|
||||
|
||||
restrict,command="GIT_ANNEX_SHELL_DIRECTORY=store GIT_ANNEX_SHELL_LIMITED=true GIT_ANNEX_SHELL_READONLY=true git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-rsa ...
|
||||
|
||||
to ~/.ssh/authorized keys and try to retrieve files.
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-annex version: 6.20180227-g32d682dd8 (standalone version) on Debian stretch
|
||||
|
||||
|
||||
### Have you had any luck using git-annex before?
|
||||
|
||||
As always, I'm a fan :>
|
||||
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2018-03-07T19:46:27Z"
|
||||
content="""
|
||||
A rsync special remote needs ssh to run rsync --server,
|
||||
you have it running git-annex-shell.
|
||||
|
||||
That can't work. It is possible to lock down generic rsync over
|
||||
ssh to only operate in one directory, but git-annex-shell
|
||||
is not the tool to do it.
|
||||
|
||||
If there's a bug here, it's whatever led you to expect this would work..
|
||||
|
||||
(But, if you make a gcrypt special remote, git-annex-shell can be used
|
||||
to access it, and it'll be all encrypted and files stored with rsync,
|
||||
and can be locked down.)
|
||||
"""]]
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://tribut.de/"
|
||||
nickname="Felix"
|
||||
avatar="http://cdn.libravatar.org/avatar/d7508a030fd9902a76b02f7feff1327e80400a1317ee98e463c68ef4c9c40bb8"
|
||||
subject="comment 2"
|
||||
date="2018-03-07T20:02:07Z"
|
||||
content="""
|
||||
OK, sorry for making this weird bug report then. I was getting errors like
|
||||
|
||||
rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell' is not rsync
|
||||
|
||||
so I assumed that my rrsync setup was incorrect and maybe it had something to do with your [recent blog](https://git-annex.branchable.com/devblog/day_486__time_to_ditch_rsync/). Unfortunately I cannot reproduce it right now, so I guess I'll wait until it happens again.
|
||||
"""]]
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://tribut.de/"
|
||||
nickname="Felix"
|
||||
avatar="http://cdn.libravatar.org/avatar/d7508a030fd9902a76b02f7feff1327e80400a1317ee98e463c68ef4c9c40bb8"
|
||||
subject="comment 3"
|
||||
date="2018-03-07T20:15:00Z"
|
||||
content="""
|
||||
Got it to happen at least (though I do not believe this is was caused me to investigate this)...
|
||||
|
||||
This works:
|
||||
|
||||
± git annex sync --content
|
||||
commit
|
||||
On branch master
|
||||
Your branch is up to date with 'origin/master'.
|
||||
|
||||
nothing to commit, working tree clean
|
||||
ok
|
||||
pull origin
|
||||
ok
|
||||
|
||||
This gives the error:
|
||||
|
||||
± git annex sync -J4 --content
|
||||
/usr/local/bin/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell inannex .' is not rsync
|
||||
|
||||
Unable to run git-annex-shell on remote .
|
||||
On branch master
|
||||
Your branch is up to date with 'origin/master'.
|
||||
|
||||
nothing to commit, working tree clean
|
||||
commit ok
|
||||
pull origin ok
|
||||
"""]]
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2018-03-07T20:25:10Z"
|
||||
content="""
|
||||
Ok, this involves the fairly recently added support for
|
||||
avoding overlapping ssh password prompts when running multiple ssh
|
||||
processes concurrently.
|
||||
|
||||
In -J mode, git-annex warms up the ssh connection by running
|
||||
"git-annex-shell inannex". Your rrsync config prevents that being run.
|
||||
|
||||
This doesn't actually cause a problem, the connection is still warmed up.
|
||||
If you needed a password to connect, it would have prompted for it before
|
||||
the error message from rrsync.
|
||||
|
||||
But it's ugly.. I've committed a fix that will avoid the ugly messages.
|
||||
"""]]
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Beginning with 8.20200522, importfeed replaces all dot (".") characters in filenames with "_". As an example, before that release, the TWIT Security Now podcast had filenames that looked like this:
|
||||
|
||||
SN_767__WiFi_6.mp3
|
||||
|
||||
After the release, the filenames look like this:
|
||||
|
||||
SN_769__Zoom_s_E2EE_Design_mp3
|
||||
|
||||
This change occurred across all my downloaded podcasts.
|
||||
|
||||
I suspect the bug has something to do with the following changes described in the news for 8.20200522:
|
||||
|
||||
- addurl, importfeed: Avoid adding filenames with leading '.', instead it will be replaced with '_'.
|
||||
- addurl, importfeed: Allow '-' in filenames, as long as it's not the first character.
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
git-annex importfeed --fast http://leoville.tv/podcasts/sn.xml
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
Arch Linux
|
||||
|
||||
git annex version 8.20200720.1-g1ccb6699a1
|
||||
|
||||
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
[git-annex Makefile: install-completions](http://source.git-annex.branchable.com/?p=source.git;a=blob;f=Makefile;h=965f53e1fc4a8f6d69041eabaccd759268f6490f;hb=HEAD#l87)
|
||||
|
||||
git-annex installs fish completions to the wrong directory. `$(SHAREDIR)/fish/completions` is the directory documented as being exclusive to completions which are shipped in the fish source code; third-party applications installing their own completions are intended to use `$(SHAREDIR)/fish/vendor_completions.d` instead.
|
||||
|
||||
See [https://fishshell.com/docs/current/index.html#completion-path](https://fishshell.com/docs/current/index.html#completion-path)
|
||||
|
||||
Note that this location can also be obtained in a similar manner to bash-completion:
|
||||
|
||||
```
|
||||
$ pkg-config bash-completion --variable=completionsdir
|
||||
/usr/share/bash-completion/completions
|
||||
```
|
||||
|
||||
```
|
||||
$ pkg-config fish --variable=completionsdir
|
||||
/usr/share/fish/vendor_completions.d
|
||||
```
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Run "make install-completions", or install a linux distribution package of git-annex that builds with the current Makefile (Arch Linux or Debian will both show the same issue).
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
Arch Linux
|
||||
|
||||
git-annex 7.20191230-7
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
Apparently this is a very common mistake :/ so far I've seen many more projects do this wrong than do it right.
|
||||
|
||||
### 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)
|
||||
|
||||
Not a user, just here to help improve cross-distro packaging. :)
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Chel"
|
||||
avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
|
||||
subject="comment 1"
|
||||
date="2020-02-03T23:34:02Z"
|
||||
content="""
|
||||
I've got an error from `make install` on version 7.20200202.7:
|
||||
|
||||
~~~
|
||||
./git-annex --fish-completion-script git-annex 2>/dev/null \
|
||||
> dest/usr/local/share/fish/completions/git-annex.fish
|
||||
make: *** [Makefile:87: install-completions] Error 2
|
||||
~~~
|
||||
|
||||
I think there should be:
|
||||
|
||||
[[!format diff \"\"\"
|
||||
diff --git a/Makefile b/Makefile
|
||||
index eb3a34e6a..722921e00 100644
|
||||
--- a/Makefile
|
||||
+++ b/Makefile
|
||||
@@ -86,7 +86,7 @@ install-completions: build
|
||||
> $(DESTDIR)$(ZSH_COMPLETIONS_PATH)/_git-annex
|
||||
install -d $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d
|
||||
./git-annex --fish-completion-script git-annex 2>/dev/null \
|
||||
- > $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/completions/git-annex.fish
|
||||
+ > $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d/git-annex.fish
|
||||
|
||||
test: git-annex git-annex-shell
|
||||
./git-annex test
|
||||
\"\"\"]]
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="eschwartz@5abb721e66990e478c7d1caf96beb4f9794eb168"
|
||||
nickname="eschwartz"
|
||||
avatar="http://cdn.libravatar.org/avatar/16ec8475b4e3507f8d1a71101c16b208"
|
||||
subject="Partial fix only."
|
||||
date="2020-02-03T23:47:35Z"
|
||||
content="""
|
||||
Looks like the install -d was changed to create the new directory, but the actual file write got left left out of the commit.
|
||||
"""]]
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2020-02-04T16:09:04Z"
|
||||
content="""
|
||||
So it did. Fixed now. Thanks for checking.
|
||||
"""]]
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
As documented in [[git-annex-matching-options]], `--copies` accepts `trustlevel` or `groupname` in the following format:
|
||||
|
||||
* `--copies=trustlevel:number`
|
||||
* `--copies=groupname:number`
|
||||
|
||||
This is ambiguous in the unlikely case where a user might come up with the idea to create a group called `trusted`, `semitrusted` or `untrusted` (`remote.<name>.annex-trustlevel`). It should thereby not be allowed to use such special groups.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
|
||||
[[!format sh """
|
||||
## In an annex repo:
|
||||
|
||||
git annex group here trusted
|
||||
|
||||
## What does this command do now?
|
||||
## For reference, it interprets it as `--copies=trustlevel:number`
|
||||
git annex find --copies=trusted:1
|
||||
|
||||
"""]]
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-annex version: 6.20180509
|
||||
build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
|
||||
dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3
|
||||
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 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
|
||||
|
||||
### 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)
|
||||
|
||||
Yes! Thanks so much for your work!
|
||||
|
||||
> Closing per comments. [[done]] --[[Joey]]
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2018-06-04T16:06:57Z"
|
||||
content="""
|
||||
Thanks for pointing out this ambiguity, which I don't remember having
|
||||
ever considered.
|
||||
|
||||
The code for this does look for the name of a trust level first,
|
||||
and only a group name if it's not a trust level. So, adding a group
|
||||
with a colliding name will never change the behavior of such a command
|
||||
or preferred content expression.
|
||||
|
||||
The only problem then would be that you couldn't match
|
||||
on a group by that name. But if you run into that problem,
|
||||
you can simply rename your group.
|
||||
|
||||
So I don't think that git-annex needs a sanity check, really.
|
||||
|
||||
(I have added a comment in the code to make clear that the order of
|
||||
parsing this does matter.)
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="ypid"
|
||||
avatar="http://cdn.libravatar.org/avatar/4286841cddc77176758dde874afe9a3a"
|
||||
subject="comment 2"
|
||||
date="2018-06-04T19:42:30Z"
|
||||
content="""
|
||||
Works for me, thanks. I also think this is not a real issue, I just noticed the edge case.
|
||||
"""]]
|
||||
|
|
@ -1,149 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
If there are multiple files with the same keys in the repository and they are copied to bup special remote,
|
||||
then `git annex fsck --from=bup` with `--jobs=N` option (N >= 2) can show an error and remove these keys from bup.
|
||||
|
||||
Based on the error message (about locked .git/annex/tmp/ file), this problem is probably not specific to bup,
|
||||
but I tested it with bup only.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
1. Configure a bup special remote.
|
||||
2. Add files with the same content to annex (and with the same backend).
|
||||
3. Copy these files to bup.
|
||||
4. Run `git annex fsck --from=bup -JN` several times, until it removes these keys from bup.
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-annex 7.20191230-g985373f8e, build from source, on Debian GNU/Linux buster.
|
||||
|
||||
bup 0.29.3-2 from Debian sid. Also tried with bup 0.30, build from source.
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format txt """
|
||||
~ $ mkdir testdir
|
||||
~ $ cd testdir
|
||||
~/testdir $
|
||||
~/testdir $ git init
|
||||
Initialized empty Git repository in /home/test/testdir/.git/
|
||||
~/testdir $
|
||||
~/testdir $ git annex init testrepo
|
||||
init testrepo (scanning for unlocked files...)
|
||||
ok
|
||||
(recording state in git...)
|
||||
~/testdir $
|
||||
~/testdir $ ls ~/.bup/index-cache/
|
||||
~/testdir $
|
||||
~/testdir $ git annex initremote bup type=bup buprepo=~/testdir/.bup encryption=none
|
||||
initremote bup (bup init...)
|
||||
Reinitialized existing Git repository in /home/test/.bup/
|
||||
Initialized empty Git repository in /home/test/testdir/.bup/
|
||||
ok
|
||||
(recording state in git...)
|
||||
~/testdir $
|
||||
~/testdir $ ls ~/.bup/index-cache/
|
||||
None__home_test_testdir__bup
|
||||
~/testdir $
|
||||
~/testdir $ echo aaa >file1
|
||||
~/testdir $ echo aaa >file2
|
||||
~/testdir $
|
||||
~/testdir $ git annex add .
|
||||
add file1
|
||||
ok
|
||||
add file2
|
||||
ok
|
||||
(recording state in git...)
|
||||
~/testdir $
|
||||
~/testdir $ git commit -m files
|
||||
[master (root-commit) 7a03b66] files
|
||||
2 files changed, 2 insertions(+)
|
||||
create mode 120000 file1
|
||||
create mode 120000 file2
|
||||
~/testdir $
|
||||
~/testdir $ git -C .bup show-ref
|
||||
~/testdir $
|
||||
~/testdir $ git annex whereis
|
||||
whereis file1 (1 copy)
|
||||
5d9b0df2-000b-4273-bc4a-fb3b9d8319bd -- testrepo [here]
|
||||
ok
|
||||
whereis file2 (1 copy)
|
||||
5d9b0df2-000b-4273-bc4a-fb3b9d8319bd -- testrepo [here]
|
||||
ok
|
||||
~/testdir $
|
||||
~/testdir $ git annex copy --to=bup .
|
||||
copy file1 (to bup...)
|
||||
|
||||
bloom: creating from 1 file (3 objects).ing: 0 kbytes
|
||||
Receiving index from server: 1156/1156, done.
|
||||
bloom: creating from 1 file (3 objects).
|
||||
ok
|
||||
copy file2 ok
|
||||
(recording state in git...)
|
||||
~/testdir $
|
||||
~/testdir $ git annex lookupkey file1 file2
|
||||
SHA256E-s4--17e682f060b5f8e47ea04c5c4855908b0a5ad612022260fe50e11ecb0cc0ab76
|
||||
SHA256E-s4--17e682f060b5f8e47ea04c5c4855908b0a5ad612022260fe50e11ecb0cc0ab76
|
||||
~/testdir $
|
||||
~/testdir $ git -C .bup show-ref
|
||||
2076647ee23ad632c8cf96caf51febbd0604452c refs/heads/SHA256E-s4--17e682f060b5f8e47ea04c5c4855908b0a5ad612022260fe50e11ecb0cc0ab76
|
||||
~/testdir $
|
||||
~/testdir $ git annex fsck --from=bup
|
||||
fsck file1
|
||||
(checksum...) ok
|
||||
fsck file2
|
||||
(checksum...) ok
|
||||
(recording state in git...)
|
||||
~/testdir $
|
||||
~/testdir $ git -C .bup show-ref
|
||||
2076647ee23ad632c8cf96caf51febbd0604452c refs/heads/SHA256E-s4--17e682f060b5f8e47ea04c5c4855908b0a5ad612022260fe50e11ecb0cc0ab76
|
||||
"""]]
|
||||
|
||||
Now run `git annex fsck --from=bup -J2` multiple times, until it drops the key from bup...
|
||||
|
||||
[[!format txt """
|
||||
~/testdir $ git annex fsck --from=bup -J2
|
||||
fsck file1 fsck file2
|
||||
|
||||
100% 4 B 5 B/s 0s
|
||||
content cannot be completely removed from bup remote
|
||||
|
||||
file2: Bad file size (4 B smaller); dropped from bup
|
||||
(checksum...)
|
||||
git-annex: .git/annex/tmp/fsck14654.SHA256E-s4--17e682f060b5f8e47ea04c5c4855908b0a5ad612022260fe50e11ecb0cc0ab76: openBinaryFile: resource busy (file is locked)
|
||||
failed
|
||||
(fixing location log) (checksum...) ok
|
||||
(recording state in git...)
|
||||
git-annex: fsck: 1 failed
|
||||
~/testdir $
|
||||
~/testdir $ git -C .bup show-ref
|
||||
~/testdir $
|
||||
~/testdir $ git annex whereis
|
||||
whereis file1 (2 copies)
|
||||
5d9b0df2-000b-4273-bc4a-fb3b9d8319bd -- testrepo [here]
|
||||
88cc362a-f87a-43c7-b194-e79b2ee91828 -- [bup]
|
||||
ok
|
||||
whereis file2 (2 copies)
|
||||
5d9b0df2-000b-4273-bc4a-fb3b9d8319bd -- testrepo [here]
|
||||
88cc362a-f87a-43c7-b194-e79b2ee91828 -- [bup]
|
||||
ok
|
||||
~/testdir $
|
||||
~/testdir $ git annex fsck --from=bup
|
||||
fsck file1 (fixing location log)
|
||||
** Based on the location log, file1
|
||||
** was expected to be present, but its content is missing.
|
||||
failed
|
||||
fsck file2 ok
|
||||
(recording state in git...)
|
||||
git-annex: fsck: 1 failed
|
||||
~/testdir $
|
||||
~/testdir $ git annex whereis
|
||||
whereis file1 (1 copy)
|
||||
5d9b0df2-000b-4273-bc4a-fb3b9d8319bd -- testrepo [here]
|
||||
ok
|
||||
whereis file2 (1 copy)
|
||||
5d9b0df2-000b-4273-bc4a-fb3b9d8319bd -- testrepo [here]
|
||||
ok
|
||||
"""]]
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-02-14T18:49:07Z"
|
||||
content="""
|
||||
Ugh, I think this could potentially result in data loss. Not when using bup,
|
||||
but other special remotes.
|
||||
|
||||
I've fixed it in git and will think about moving the date of the next
|
||||
release up.
|
||||
"""]]
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
I looked into post-receive hook of an arbitrary git/git-annex repo to find
|
||||
|
||||
[[!format sh """
|
||||
(git-annex)hopa:/tmp/testds/.git/hooks[master]
|
||||
$> cat post-receive
|
||||
#!/bin/sh
|
||||
# automatically configured by git-annex
|
||||
if git annex post-receive --help >/dev/null 2>&1; then git annex post-receive; fi
|
||||
"""]]
|
||||
|
||||
and wondered why it actually needs conditioning? `--help` runs for me longer (40-50ms) than actual `git annex post-receive` call (20ms) when there is nothing todo. So I wondered why wasting time on `--help`?
|
||||
|
||||
[[!meta author=yoh]]
|
||||
|
||||
> [[done]], there does not seem to be a bug here. --[[Joey]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2019-09-27T16:57:30Z"
|
||||
content="""
|
||||
Old versions of git-annex didn't have a post-receive command,
|
||||
so initailizing with a new git-annex and then using an old one would be a
|
||||
problem without this check.
|
||||
"""]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2019-09-30T17:36:40Z"
|
||||
content="""
|
||||
Of course if you're sure you'll never use an old version of git-annex
|
||||
(or don't care if the hook breaks if you do), you can modify the hook
|
||||
script.
|
||||
|
||||
I don't see any changes I should make here, can this bug report be closed?
|
||||
"""]]
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
### 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 :)
|
||||
|
||||
> This is not a bug in the test suite, it turns out, but in
|
||||
> git-annex's handling of a http remote. It was throwing fatal errors
|
||||
> rather than the correct behavior of displaying a warning. [[fixed|done]]
|
||||
> --[[Joey]]
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
### Please describe the problem.
|
||||
Running fsck on a remote completely drops the file
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
* Create a standard git annex repo
|
||||
* Set up another remote (I used a standard git annex repo) in it
|
||||
* Corrupt a file in the remote repo. Changing one byte is sufficient for this
|
||||
* Run `git-annex fsck`
|
||||
* git-annex will notice the corruption and completely drop the file from the remote
|
||||
|
||||
I expect git-annex to never drop data unless specified as also mentioned [here](https://git-annex.branchable.com/walkthrough/fsck__58___when_things_go_wrong)
|
||||
|
||||
I would rather look at the corrupted file myself and figure out the best course of action instead of losing it completely.
|
||||
|
||||
At this point, I'm working around it by not running fsck on remotes, since local fsck seems to work as expected.
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
8.20200309, Mac
|
||||
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
~~~
|
||||
$ git-annex fsck --from=origin
|
||||
fsck dir1/dir1_file1 (checksum...) ok
|
||||
fsck dir1/dir1_file2 (checksum...) ok
|
||||
fsck file1 (checksum...)
|
||||
file1: Bad file content; dropped from origin
|
||||
failed
|
||||
fsck file2 (checksum...) ok
|
||||
(recording state in git...)
|
||||
git-annex: fsck: 1 failed
|
||||
~~~
|
||||
|
||||
### 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)
|
||||
Yes it stores most of my data
|
||||
|
||||
> [[notabug|done]] --[[Joey]]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-06-30T14:33:08Z"
|
||||
content="""
|
||||
The corrupted file is downloaded from the remote, and that copy of the file
|
||||
gets moved to .git/annex/bad/ when fsck determines it's corrupt. A message
|
||||
is displayed giving the path where the content is left.
|
||||
|
||||
The only time that's not done is if the local repository has its own copy
|
||||
of the file. In that case, there's not much benefit to accumulating bad
|
||||
copies in .git/annex/bad since there's still a (presumably) good copy.
|
||||
|
||||
If fsck left corrupted content on the remote, that would risk actual data
|
||||
loss. Consider if a second repository also had access to the remote, and
|
||||
in that repository you ran git-annex drop. It would see that the remote
|
||||
still contains the file, so assume the content is good, and so go ahead and
|
||||
drop the content from the second repository. That might be the only
|
||||
uncorrupted copy of the file it's lost. So once we know that the content is
|
||||
corrupt, the safe thing to do is move it out of the way.
|
||||
"""]]
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
I created a dataset with datalad and added multiple remotes/buckets on a private S3-like server (minio).
|
||||
On the HPC I am able to get the data and push it.
|
||||
On another machine, I cannot get the data, here are the debug info.
|
||||
|
||||
|
||||
$ git-annex get -v -d --from s3unf.phantom.anat.mri sub-01/ses-ana001/anat/sub-01_ses-ana001_T1w.nii.gz
|
||||
[2020-02-21 16:20:09.399086] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||
[2020-02-21 16:20:09.405552] process done ExitSuccess
|
||||
[2020-02-21 16:20:09.405884] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||
[2020-02-21 16:20:09.411446] process done ExitSuccess
|
||||
[2020-02-21 16:20:09.413223] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..050f99f2712d25b581b58a3adc6af83b8d5345b0","--pretty=%H","-n1"]
|
||||
[2020-02-21 16:20:09.419815] process done ExitSuccess
|
||||
[2020-02-21 16:20:09.420835] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||
[2020-02-21 16:20:09.421976] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
|
||||
[2020-02-21 16:20:09.456813] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
|
||||
[2020-02-21 16:20:09.462354] process done ExitSuccess
|
||||
[2020-02-21 16:20:09.462577] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
|
||||
[2020-02-21 16:20:09.468639] process done ExitSuccess
|
||||
[2020-02-21 16:20:09.468923] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","sub-01/ses-ana001/anat/sub-01_ses-ana001_T1w.nii.gz"]
|
||||
get sub-01/ses-ana001/anat/sub-01_ses-ana001_T1w.nii.gz (from s3unf.phantom.anat.mri...)
|
||||
[2020-02-21 16:20:09.585446] String to sign: "GET\n\n\nFri, 21 Feb 2020 21:20:09 GMT\n/phantom.anat.mri/SHA256E-s28509481-S1073741824-C1--7eb345c88a120d934cb390ad0385149cb6ae8540a2ed6689251cba22b7832306.nii.gz"
|
||||
[2020-02-21 16:20:09.585844] Host: "<redacted_hostname>"
|
||||
[2020-02-21 16:20:09.586001] Path: "/phantom.anat.mri/SHA256E-s28509481-S1073741824-C1--7eb345c88a120d934cb390ad0385149cb6ae8540a2ed6689251cba22b7832306.nii.gz"
|
||||
[2020-02-21 16:20:09.586261] Query string: ""
|
||||
[2020-02-21 16:20:09.586423] Header: [("Date","Fri, 21 Feb 2020 21:20:09 GMT"),("Authorization","AWS manager:k/aaaaaaaaaaaaaaaaaaaaaa=")]
|
||||
[2020-02-21 16:20:09.593542] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
|
||||
[2020-02-21 16:20:09.594433] String to sign: "GET\n\n\nFri, 21 Feb 2020 21:20:09 GMT\n/phantom.anat.mri/SHA256E-s28509481--7eb345c88a120d934cb390ad0385149cb6ae8540a2ed6689251cba22b7832306.nii.gz"
|
||||
[2020-02-21 16:20:09.594667] Host: "<redacted_hostname>"
|
||||
[2020-02-21 16:20:09.594819] Path: "/phantom.anat.mri/SHA256E-s28509481--7eb345c88a120d934cb390ad0385149cb6ae8540a2ed6689251cba22b7832306.nii.gz"
|
||||
[2020-02-21 16:20:09.595006] Query string: ""
|
||||
[2020-02-21 16:20:09.595153] Header: [("Date","Fri, 21 Feb 2020 21:20:09 GMT"),("Authorization","AWS manager:wwwwwwwwwwwwwwwwwww ")]
|
||||
[2020-02-21 16:20:09.596938] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
|
||||
failed
|
||||
[2020-02-21 16:20:09.600838] process done ExitSuccess
|
||||
[2020-02-21 16:20:09.601651] process done ExitSuccess
|
||||
git-annex: get: 1 failed
|
||||
|
||||
|
||||
When running that command, no request is sent to the server!? (in minio trace logs), but I don't know why.
|
||||
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
latest package in conda-forge on ubuntu
|
||||
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### 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)
|
||||
|
||||
Yes.
|
||||
|
||||
> [[closing|done]] since bug reporter says it works for them now after some
|
||||
> change, and is not responding to my followups. --[[Joey]]
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
|
||||
nickname="basile.pinsard"
|
||||
avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
|
||||
subject="comment 10"
|
||||
date="2020-02-28T15:44:50Z"
|
||||
content="""
|
||||
@joey
|
||||
|
||||
I am now trying from scratch, created a new repository and trying to create the remote from the server to the S3 on the same network.
|
||||
|
||||
```
|
||||
git-annex config --set annex.security.allowed-ip-addresses 10.10.10.20
|
||||
git annex initremote -d s3.test type=S3 encryption=none autoenable=true host=s3.unf-montreal.ca port=443 protocol=https chunk=1GiB bucket=test requeststyle=path
|
||||
```
|
||||
|
||||
I get the following error despite relaxing the security option. (same thing with 'all' instead of 10.10.10.20).
|
||||
|
||||
Maybe this security check is broken, and this is why I have problem just getting data from the local network?
|
||||
|
||||
|
||||
```
|
||||
(InternalException (ConnectionRestricted \"Configuration of annex.security.allowed-ip-addresses does not allow accessing address 10.10.10.20\"))
|
||||
```
|
||||
|
||||
Also, when I add the option exporttree=no
|
||||
|
||||
```
|
||||
git-annex: Unexpected parameters: exporttree
|
||||
failed
|
||||
```
|
||||
|
||||
while the option exists in the doc, and I used it in the past.
|
||||
|
||||
Version
|
||||
|
||||
```
|
||||
$ git-annex version
|
||||
git-annex version: 7.20200219-g5094a3f
|
||||
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.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 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
|
||||
local repository version: 7
|
||||
```
|
||||
|
||||
|
||||
Thank you for your help.
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 11"""
|
||||
date="2020-02-28T17:51:47Z"
|
||||
content="""
|
||||
You need to use git config to set that, not git-annex config.
|
||||
|
||||
git-annex config can only be used with a few carefully
|
||||
chosen configuration settings that make sense to
|
||||
apply to all clones of the repository. annex.security.allowed-ip-addresses
|
||||
is not amoung those. This is clearly documented in the git-annex config man
|
||||
page IMHO, but I'm always interested to learn about problems with
|
||||
documentation.
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 12"""
|
||||
date="2020-02-28T17:55:48Z"
|
||||
content="""
|
||||
I'd be interested in a separate bug report about exporttree=no not being
|
||||
accepted by git-annex. (I just tried it myself with a S3 remote and it was
|
||||
accepted, but maybe I don't completely understand what you did.)
|
||||
"""]]
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
|
||||
nickname="basile.pinsard"
|
||||
avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
|
||||
subject="comment 13"
|
||||
date="2020-02-28T20:20:09Z"
|
||||
content="""
|
||||
> You need to use git config to set that, not git-annex config.
|
||||
|
||||
Unless I am getting crazy, I am pretty sure I managed to make that command work before with git-annex (the --set option is not in the git config syntax), so I wrote it in my own doc a few months back. In the git-repo I ran it before, the .git/config file contains the option.
|
||||
|
||||
The command returns a nice message that made me think it worked:
|
||||
|
||||
```
|
||||
$ git-annex config --set annex.security.allowed-ip-addresses 10.10.10.20
|
||||
annex.security.allowed-ip-addresses 10.10.10.20 ok
|
||||
(recording state in git...)
|
||||
```
|
||||
|
||||
- About the doc, I am not sure if I got the command from the man page. Maybe an example of how to set these variables with git config (`git config --add <name> <value>`) in the man page would avoid this kind of mistakes from dumb users like me ;). Maybe I thought that git-annex-config also change .git/config file.
|
||||
|
||||
- The ConnectionRestricted for annex.security.allowed-ip-addresses do not show-up when trying to get data from a clone of the git where the remote was configured after correctly setting that option. That is why there was no traffic out except the DNS request.
|
||||
|
||||
- Maybe git-annex config should not return a nice message when trying to set an unknown option.
|
||||
|
||||
I will open a separate bug for the exporttree shortly.
|
||||
|
||||
Now it works!
|
||||
Thanks for your help!
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 14"""
|
||||
date="2020-03-02T19:03:44Z"
|
||||
content="""
|
||||
It's true that you can currently use git-annex config to set absolutely any
|
||||
value, but git-annex only looks at the values that are listed in the
|
||||
documentation.
|
||||
|
||||
I suppose I'll change it to reject other values.
|
||||
|
||||
----
|
||||
|
||||
So, you say it works, but I still don't understand the behavior you
|
||||
originally reported. Have you somehow fixed it? Or just not reproduced it
|
||||
with your new from scratch repository?
|
||||
"""]]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
|
||||
nickname="basile.pinsard"
|
||||
avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
|
||||
subject="no traffic getting out"
|
||||
date="2020-02-25T16:55:23Z"
|
||||
content="""
|
||||
Things are getting weirder.
|
||||
There is no traffic coming out of my machine (`tcpdump`) when running the `git-annex get`.
|
||||
When I run curl pointing to the same https address, it works, the server receives the request.
|
||||
I tried the standalone version, different versions from ubuntu repos, conda-forge, all the same on Ubuntu 18.04 machines, finally from a docker-container with anaconda (debian-based I think), same thing.
|
||||
|
||||
When I connect to my cellphone as a hotspot, it works!
|
||||
Is there any way to have more debug from the S3 remote code, or from haskell S3 or network packages?
|
||||
|
||||
I am loosing my mind here.
|
||||
Help :/
|
||||
|
||||
Thanks!
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-02-25T17:24:51Z"
|
||||
content="""
|
||||
It certianly seems to have sent a request to *somewhere*,
|
||||
since it gets back a response:
|
||||
|
||||
[2020-02-21 16:20:09.596938] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
|
||||
|
||||
Kind of looks like that response is not the response that a S3 server
|
||||
should generate, since it's missing the usual metadata.
|
||||
"""]]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2020-02-25T17:35:02Z"
|
||||
content="""
|
||||
Unfortunately --debug is all the debug info that's available.
|
||||
|
||||
One possibility that comes to mind is a http proxy. Perhaps curl is
|
||||
using some proxy that is necessary to get data out, and git-annex is not.
|
||||
|
||||
By default, git-annex avoids connections to local IP adddresses,
|
||||
for security reasons. If you have a local http proxy, it won't use it
|
||||
either. You could try this:
|
||||
|
||||
git config annex.security.allowed-ip-addresses all
|
||||
"""]]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2020-02-25T17:45:07Z"
|
||||
content="""
|
||||
Hmm, git-annex does display a big warning message if there's a local proxy
|
||||
that its security does not allow it to use.
|
||||
|
||||
Still, annex.security.allowed-ip-addresses seems like the only likely
|
||||
reason git-annex would not connect to a server while curl does.
|
||||
"""]]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
|
||||
nickname="basile.pinsard"
|
||||
avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
|
||||
subject="comment 5"
|
||||
date="2020-02-26T13:46:22Z"
|
||||
content="""
|
||||
Yes the local IP is already listed in the security parameters, the error message was quite informative.
|
||||
There are no proxy configured on any of the machines.
|
||||
tcpdump should show me any data going out to the server.
|
||||
|
||||
I looked at the AWS.S3 package, and it seems some bucket resolve function might rely on the DNS, correct me if I am wrong.
|
||||
The requeststyle is set to path as this is what minio can provide, so the
|
||||
Could it be that the local DNS do not support some functions that S3 rely on?
|
||||
However, I already created remotes and pushed data from these servers in the past and I don't think the DNS server has changed since.
|
||||
|
||||
As the hotspot test shows, this is an interaction of the local network configuration with git-annex+dependencies code, but I can't figure out how to debug that.
|
||||
|
||||
Thanks.
|
||||
"""]]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
|
||||
nickname="basile.pinsard"
|
||||
avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
|
||||
subject="strace"
|
||||
date="2020-02-26T15:50:50Z"
|
||||
content="""
|
||||
Running strace to monitor network, I get the following errors regarding nscd, though this socket is not here either when running the hotspot test:
|
||||
```
|
||||
[pid 23666] connect(18, {sa_family=AF_UNIX, sun_path=\"/var/run/nscd/socket\"}, 110) = -1 ENOENT (No such file or directory)
|
||||
[pid 23666] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 17
|
||||
[pid 23666] connect(17, {sa_family=AF_UNIX, sun_path=\"/var/run/nscd/socket\"}, 110) = -1 ENOENT (No such file or directory)
|
||||
[pid 23666] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 17
|
||||
[pid 23666] connect(17, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(\"127.0.0.53\")}, 16) = 0
|
||||
```
|
||||
"""]]
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 7"""
|
||||
date="2020-02-26T17:58:05Z"
|
||||
content="""
|
||||
DNS is typically needed yes. That it gets a http response
|
||||
from some server seems to imply it's able to resolve the IP address of
|
||||
the server. So I'd guess DNS is not the problem, unless it's resolving the
|
||||
*wrong* IP address and connecting to the wrong server. Which would be
|
||||
consistent with tcpdump not showing any traffic to the server.
|
||||
|
||||
ncsd can be configured on some systems to do DNS lookups. It's normal
|
||||
for glibc to try to connect to nscd for a DNS lookup and fall back to a
|
||||
regular lookup when it's not installed. That seems to be all your strace is
|
||||
showing.
|
||||
|
||||
The next line of your strace shows it connecting to 127.0.0.53
|
||||
That seems to be an address systemd sets up to use resolvd for dns.
|
||||
That connection seems to succeed, so I guess dns resolution proceeds using
|
||||
resolved.
|
||||
|
||||
All this DNS stuff is completely normal glibc name resolution as far as I
|
||||
can see.
|
||||
|
||||
My suggestion is to tcpdump the entire network traffic when git-annex is
|
||||
running, and analize that.
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
|
||||
nickname="basile.pinsard"
|
||||
avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
|
||||
subject="comment 8"
|
||||
date="2020-02-26T19:11:53Z"
|
||||
content="""
|
||||
The only relevant traffic when running the `git-annex get` is the DNS call for the A record, the answer from the DNS is right (and AAAA record but no IPV6 on our network so 0 results).
|
||||
"""]]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
|
||||
nickname="basile.pinsard"
|
||||
avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
|
||||
subject="comment 9"
|
||||
date="2020-02-26T19:15:11Z"
|
||||
content="""
|
||||
The only difference in the `dig` answer when running from the outside is additional answer sections:
|
||||
```
|
||||
;; AUTHORITY SECTION:
|
||||
<redacted_domain>. 3600 IN NS ns22.domaincontrol.com.
|
||||
<redacted_domain>. 3600 IN NS ns21.domaincontrol.com.
|
||||
|
||||
;; ADDITIONAL SECTION:
|
||||
ns22.domaincontrol.com. 21 IN A 173.201.68.11
|
||||
ns22.domaincontrol.com. 21 IN AAAA 2603:5:2241::b
|
||||
ns21.domaincontrol.com. 21 IN A 97.74.100.11
|
||||
ns21.domaincontrol.com. 21 IN AAAA 2603:5:2141::b
|
||||
|
||||
```
|
||||
"""]]
|
||||
|
|
@ -1,82 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Latest git-annex commit 93520790a still doesn't quite compile without a small patch :)
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
`stack setup && stack build`
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
[[!format sh """
|
||||
git-annex version: 8.20201117-g93520790a
|
||||
build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
|
||||
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
|
||||
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
|
||||
operating system: mingw32 x86_64
|
||||
supported repository versions: 8
|
||||
upgrade supported from repository versions: 2 3 4 5 6 7
|
||||
"""]]
|
||||
|
||||
Windows version 20H2 (build 19042.630), 64 bit.
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
Relevant parts of the build log:
|
||||
|
||||
[[!format sh """
|
||||
jkniiv@AINESIS:/c/Projektit/git-annex.branchable.com/git-annex--BUILD-201125-93520790a$ tail -n 25 stack.build.LOG~102
|
||||
[326 of 644] Compiling P2P.IO
|
||||
[327 of 644] Compiling CmdLine.GitRemoteTorAnnex
|
||||
[328 of 644] Compiling Annex.CheckIgnore
|
||||
[329 of 644] Compiling Annex.CheckAttr
|
||||
[330 of 644] Compiling Backend
|
||||
[331 of 644] Compiling Annex.Transfer
|
||||
[332 of 644] Compiling Annex.CatFile
|
||||
[333 of 644] Compiling RemoteDaemon.Common
|
||||
[334 of 644] Compiling Database.Keys
|
||||
[335 of 644] Compiling Upgrade.V7
|
||||
[336 of 644] Compiling Annex.Content.Presence
|
||||
|
||||
Annex\Content\Presence.hs:122:85: error:
|
||||
* Variable not in scope: removeLink :: FilePath -> IO ()
|
||||
* Perhaps you meant one of these:
|
||||
`R.removeLink' (imported from Utility.RawFilePath),
|
||||
`removeFile' (imported from Annex.Common)
|
||||
|
|
||||
122 | void $ tryIO $ removeWhenExistsWith removeLink (fromRawFilePath lockfile)
|
||||
| ^^^^^^^^^^
|
||||
|
||||
|
||||
-- While building package git-annex-8.20201116 (scroll up to its section to see the error) using:
|
||||
C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-201125-93520790a\.stack-work\dist\29cc6475\setup\setup --builddir=.stack-work\dist\29cc6475 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
|
||||
Process exited with code: ExitFailure 1
|
||||
# End of transcript.
|
||||
"""]]
|
||||
|
||||
The change I ended up making was:
|
||||
|
||||
[[!format diff """
|
||||
diff --git a/Annex/Content/Presence.hs b/Annex/Content/Presence.hs
|
||||
index 4b33bcefb..05ff5715e 100644
|
||||
--- a/Annex/Content/Presence.hs
|
||||
+++ b/Annex/Content/Presence.hs
|
||||
@@ -119,7 +119,7 @@ inAnnexSafe key = inAnnex' (fromMaybe True) (Just False) go key
|
||||
Nothing -> return is_locked
|
||||
Just lockhandle -> do
|
||||
dropLock lockhandle
|
||||
- void $ tryIO $ removeWhenExistsWith removeLink (fromRawFilePath lockfile)
|
||||
+ void $ tryIO $ removeWhenExistsWith R.removeLink lockfile
|
||||
return is_unlocked
|
||||
, return is_missing
|
||||
)
|
||||
"""]]
|
||||
|
||||
This then compiled cleanly.
|
||||
|
||||
### 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)
|
||||
|
||||
Git Annex is great. It works with multi-gigabyte backup files via the MD5E backend just dandy :)
|
||||
|
||||
> [[fixed|done]], thanks for the patch --[[Joey]]
|
||||
|
|
@ -1,104 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Running the test QuickCheck.prop_viewedFile_rountrips fails in a particular case (but only occasionally).
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Running the following fails:
|
||||
|
||||
[[!format sh """
|
||||
jkniiv@AINESIS MINGW64 /c/annx
|
||||
$ ./git-annex.exe test -p 'QuickCheck.prop_viewedFile_rountrips' --quickcheck-replay=819461 --quickcheck-verbose 2>&1 | tee git-annex.test--p-QuickCheck_prop_viewedFile_rountrips.LOG~201
|
||||
[...]
|
||||
$ cat git-annex.test--p-QuickCheck_prop_viewedFile_rountrips.LOG~201
|
||||
Tests
|
||||
QuickCheck
|
||||
prop_viewedFile_rountrips: FAIL (0.01s)
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "{\DC4"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = ":"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "\SI"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "\"78"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "[:"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "\ax0"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "_\SUB"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "\DC1"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "wP["}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "8gp\v\DC38"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "cO\ESC\FS]"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "("}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "3\ESCLK=\SOH"}
|
||||
|
||||
Passed:
|
||||
TestableFilePath {fromTestableFilePath = "21U'd(\DEL("}
|
||||
|
||||
Failed:
|
||||
TestableFilePath {fromTestableFilePath = "C:"}
|
||||
|
||||
*** Failed! Falsified (after 15 tests):
|
||||
TestableFilePath {fromTestableFilePath = "C:"}
|
||||
Use --quickcheck-replay=819461 to reproduce.
|
||||
|
||||
1 out of 1 tests failed (0.01s)
|
||||
(Failures above could be due to a bug in git-annex, or an incompatibility
|
||||
with utilities, such as git, installed on this system.)
|
||||
# End of transcript.
|
||||
"""]]
|
||||
|
||||
If you remove the option `--quickcheck-replay=819461`, the test usually passes.
|
||||
|
||||
As you can see, the test above supposedly generated a file named "C:" which in its particular use case caused problems.
|
||||
N.B. Git Bash (and thus MSYS2 or Cygwin) doesn't have any problem creating a file named "C:" (`touch 'C:'`) nor deleting it (`rm 'C:'`)
|
||||
so I guess it isn't an illegal name in Windows as such but somehow git-annex managed to ruffle its feathers nonetheless.
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
[[!format sh """
|
||||
git-annex version: 8.20201117-g93520790a
|
||||
build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
|
||||
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.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 X*
|
||||
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
|
||||
operating system: mingw32 x86_64
|
||||
supported repository versions: 8
|
||||
upgrade supported from repository versions: 2 3 4 5 6 7
|
||||
"""]]
|
||||
|
||||
This is built with the additional patch mentioned in [[bugs/Small_patch_to_make_93520790a_compile_on_Windows]].
|
||||
|
||||
Windows version 20H2 (build 19042.630), 64 bit.
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
(The transcript is above.)
|
||||
|
||||
### 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)
|
||||
|
||||
Git Annex is great. It works with multi-gigabyte backup files via the MD5E backend just dandy :)
|
||||
|
||||
> [[fixed|done]] in [[!commit e92117bfd0d28b24f51a10903158b95010defffd]]
|
||||
> --[[Joey]]
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
### Please describe the problem.
|
||||
I get the following **warning** on my git-annex dashboard
|
||||
|
||||
```
|
||||
Upgrader crashed: C:\Users\alexasus\.config\git-annex\program: openFile: does not exist (No such file or directory)
|
||||
```
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
- Install git-annex with the Windows 10 installer.
|
||||
- Create a repository with the default path.
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
- git-annex version: git-annex-installer_8.20201007+git171-g7e24b2587 (this is the Windows 10 installer filename)
|
||||
- Windows 10 Version 2004 (OS Build 19041.630)
|
||||
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
|
||||
[2020-11-18 11:29:22.6950775] main: starting assistant version 8.20201008-g7e24b2587
|
||||
Launching web browser on file://C:\Users\alexasus\Desktop\annex\.git\annex\webapp.html
|
||||
[2020-11-18 11:29:22.7940807] Cronner: You should enable consistency checking to protect your data.
|
||||
(scanning...) [2020-11-18 11:29:23.278062] Watcher: Performing startup scan
|
||||
(started...)
|
||||
Upgrader crashed: C:\Users\alexasus\.config\git-annex\program: openFile: does not exist (No such file or directory)
|
||||
[2020-11-18 11:29:24.1010593] Upgrader: warning Upgrader crashed: C:\Users\alexasus\.config\git-annex\program: openFile: does not exist (No such file or directory)
|
||||
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### 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 barely just installed. So I'm gonna get going these days. That warning doesn't seem to be an issue so far. I've looked it up but couldn't find any other reports for that warning.
|
||||
|
||||
|
||||
|
||||
> [[fixed|done]] (by skipping checking upgrades on OS's where it's not
|
||||
> supported) --[[Joey]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-11-19T16:46:50Z"
|
||||
content="""
|
||||
Thanks for reporting. You do not need to worry about this, it seems we
|
||||
accidentially enabled trying to upgrade in the recent release for windows,
|
||||
but git-annex has never actually supported upgrading itself on windows,
|
||||
so of course it fails.
|
||||
"""]]
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
I was git-annex-adding a folder of big files.
|
||||
I ran the command while inside a folder I didn't need anymore.
|
||||
I deleted the folder with nautilus (moved it to trash) which caused the cwd to change and that really confused git-annex.
|
||||
|
||||
Root of repo is audio-recordings/
|
||||
|
||||
While inside audio-recordings/a I ran `git annex add ../audio-files`
|
||||
|
||||
Then I deleted audio-recordings/a with Nautilus which caused its path to change to /.Trash-1000/files/a
|
||||
|
||||
As soon as git-annex finished hashing the file it was hashing, this happened:
|
||||
|
||||
```
|
||||
add ../audio-files/moto-maxx/2018.04.17 1438.wav
|
||||
100% 579.95 MiB 160 MiB/s 0s
|
||||
../audio-files/moto-maxx/2018.04.17 1438.wav changed while it was being added
|
||||
failed
|
||||
fatal: not a git repository: '../.git'
|
||||
error: unknown option `cached'
|
||||
usage: git diff --no-index [<options>] <path> <path>
|
||||
...
|
||||
[the entire help message]
|
||||
...
|
||||
--find-object <object-id>
|
||||
look for differences that change the number of occurrences of the specified object
|
||||
--diff-filter [(A|C|D|M|R|T|U|X|B)...[*]]
|
||||
select files by diff type
|
||||
--output <file> Output to a specific file
|
||||
|
||||
(recording state in git...)
|
||||
fatal: not a git repository: '../.git'
|
||||
^Ceral-pathspecs","add","--"] exited 123)
|
||||
|
||||
```
|
||||
|
||||
The file that was being added was left like this:
|
||||
|
||||
```
|
||||
ll "audio-files/moto-maxx/2018.04.17 1438.wav"
|
||||
|
||||
-r--r--r-- 2 ### ### 608121644 abr 17 2018 'audio-files/moto-maxx/2018.04.17 1438.wav'
|
||||
```
|
||||
|
||||
It appears git-annex just chmoded it, but didn't symlinkify it.
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
`Ubuntu 20.04 focal`
|
||||
|
||||
`Linux 5.8.0-050800-generic`
|
||||
|
||||
`git-annex version: 8.20200226`
|
||||
|
||||
### 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 am absolutely in love with it. I even built a special remote for it and I'm now building another because that one was stupid.
|
||||
|
||||
Seriously, git-annex is amazing.
|
||||
|
||||
***
|
||||
|
||||
## edit:
|
||||
|
||||
Turns out this "bug" affects pretty much everything.
|
||||
|
||||
TL;DR: relative path access will be made relative to the new location if you move a directory that's got something running in it, so don't.
|
||||
|
||||
[[done]]
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-08-06T18:01:23Z"
|
||||
content="""
|
||||
Thanks, I was able to reproduce this easily:
|
||||
|
||||
git init r
|
||||
cd r
|
||||
mkdir a
|
||||
mkdir b
|
||||
dd if=/dev/zero of=a/big bs=1M count=1000
|
||||
cd b
|
||||
git annex add ../a & (sleep 1; mv ../b ~/trash)
|
||||
|
||||
By moving the directory the process is running in, all relative path
|
||||
accesses it does after the move are relative to the new location. This is
|
||||
super unsafe, but I don't know if it's super unsafe in a way that's unique to
|
||||
git-annex. If a process does any relative path accesses with ../ in them,
|
||||
it's going to be vulnerable to being flung around in this way and will start
|
||||
to do unexpected things.
|
||||
|
||||
git seems to avoid this being a problem by starting with a chdir to the top
|
||||
of the repo, and then uses relative paths without ../. (Mostly.. --git-dir
|
||||
with ../ in it will make git use such paths.)
|
||||
|
||||
Other commands.. not so much. `rm -rf ../foo` ends by unlinking "../foo"
|
||||
so if it's flung around it will delete the wrong thing. (Though its
|
||||
directory tree traversal uses openat() and so avoids deleting a whole wrong
|
||||
directory tree.) And `vim ../foo` overwrote an existing file after being
|
||||
moved, bypassing its usual protections about overwriting a modified file.
|
||||
|
||||
So, I think the super unsafe thing is generally moving directories around
|
||||
when they have processes running in them. Unfortunately, the file manager
|
||||
has a good reason to want to do it to handle deletions too.. Well, my
|
||||
opinion of unix's safety was already not great, but it's now gone down some
|
||||
more.
|
||||
|
||||
(Fun thing to consider: What if you have the ability to move a directory
|
||||
that a root-owned process is running in, and the root-owned process does
|
||||
relative paths accesses? This seems like it could be a fertile source of
|
||||
security holes.)
|
||||
|
||||
----
|
||||
|
||||
The git error message about the cached option happen when "git diff
|
||||
--cached" is run outside a git repository. Why is it outside a git
|
||||
repository? See above. So I don't think it can be avoided.
|
||||
|
||||
Only improvement that seems feasible is, to keep an open handle to the
|
||||
file, so it can fchmod the fix the permissions back.
|
||||
"""]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="cardoso-neto"
|
||||
avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
|
||||
subject="Understood."
|
||||
date="2020-08-07T02:24:43Z"
|
||||
content="""
|
||||
Thank you for the detailed and timely response.
|
||||
|
||||
That was some good thinking there with this being a possible attack vector. Food for thought right there.
|
||||
|
||||
Btw, I'm sorry for explaining what I did instead of providing you with commands to reproduce the bug. I don't know what I was thinking. Git-annex has been a very big part of my life these last few years and I got a little nervous while writing the bug report. lol
|
||||
|
||||
I shall be more careful with from where I run my commands henceforth.
|
||||
"""]]
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
When running git-annex tests on a specific machine I get the following error:
|
||||
|
||||
```
|
||||
$ ./dist-newstyle/build/x86_64-linux/ghc-8.6.5/git-annex-8.20200226/build/git-annex/git-annex test -v -p Tests.QuickCheck.prop_hashes_stable
|
||||
Tests
|
||||
QuickCheck
|
||||
prop_hashes_stable: Illegal instruction (core dumped)
|
||||
```
|
||||
|
||||
(I get the same error when just running `./dist-newstyle/build/x86_64-linux/ghc-8.6.5/git-annex-8.20200226/build/git-annex/git-annex test`, but after successful passes of previous tests.)
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Run the following on a machine with the CPU "AMD Phenom(tm) II X3 720 Processor":
|
||||
|
||||
```
|
||||
git clone git://git-annex.branchable.com/ git-annex
|
||||
cd git-annex
|
||||
cabal install -j --only-dependencies
|
||||
cabal configure
|
||||
cabal build -j
|
||||
./dist-newstyle/build/x86_64-linux/ghc-8.6.5/git-annex-8.20200226/build/git-annex/git-annex test -v -p Tests.QuickCheck.prop_hashes_stable
|
||||
```
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
I'm trying to build git-annex from the current "master". However, the same problem exists in 7.20190819, 7.20191230 and 7.20200204.
|
||||
|
||||
I'm building on NixOS, release 19.09, using GHC 8.6.5.
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
I believe the problem was initially encountered on NixOS' build farm, https://hydra.nixos.org/ , when trying to build the git-annex package version 7.20190819 for NixOS/nixpkgs. (As a result, the built package was not available when I tried to update my installation of NixOS, which led me to investigating this problem.)
|
||||
|
||||
So I tried to build the same package (and other versions, see above) on my own machine running NixOS (which has AMD Phenom II CPU). It consistently failed during testing on numerous attempts with different configurations. However, another machine (with AMD FX-8300 CPU) was able to build the same package, and never had the same test failures.
|
||||
|
||||
Then I built git-annex on both machines from source (not as a Nix package), using cabal, and tried to run tests, as shown in the beginning. I got the same results: Phenom II failed the test Tests.QuickCheck.prop_hashes_stable with "Illegal instruction", while FX-8300 passed it.
|
||||
|
||||
I do **not** think that my Phenom II machine has hardware problems: I ran MemTest recently, and this machine is able to build other packages (including GCC and GHC) just fine.
|
||||
|
||||
Moreover, the same problem occurs on hydra.hixos.org , and it looks like it's sporadic (repeating the build can fix it). I guess that this depends on which machine is assigned to build the package: some machines are able to build it, while others are not.
|
||||
|
||||
So, my hypothesis is that git-annex's tests (and maybe non-test code pieces as well) use some CPU instructions that are not supported on Phenom II (and other) CPUs, but supported on later CPUs such as FX-8300. Probably this is even a problem of GHC rather than of git-annex, but I'm not qualified to tell (I know nothing relevant about Haskell compilation or code generation).
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
|
||||
[nix-shell:~/build/git-annex]$ ./dist-newstyle/build/x86_64-linux/ghc-8.6.5/git-annex-8.20200226/build/git-annex/git-annex test -v -p Tests.QuickCheck.prop_hashes_stable
|
||||
Illegal instruction (core dumped)
|
||||
|
||||
[nix-shell:~/build/git-annex]$ dmesg | tail -n1
|
||||
[151755.340563] traps: git-annex:w[20112] trap invalid opcode ip:2d6c567 sp:7fefa0a1fd98 error:0 in git-annex[407000+313b000]
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### 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'm using git-annex as a core of the simple in-house system that handles storage, transfer and tracking of multi-GB data sets, taking advantage of git for version tracking, git-annex for data storage and transfer, and a single SSH access point to both of them.
|
||||
|
||||
I must admit that it was a pain to adapt git-annex to my needs, and probably I did it in a manner that wasn't an intended/supported way of using git-annex. But it does the job.
|
||||
|
||||
> [[closing|done]] as it's a bug in cryptonite --[[Joey]]
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-03-02T17:48:17Z"
|
||||
content="""
|
||||
The failing test case is testing all the hashes that git-annex uses.
|
||||
Quite likely what has happened is that the hash implementation has been
|
||||
built with a CPU-specific optimisation that is not available on your AMD.
|
||||
|
||||
The hash implementations are in http://hackage.haskell.org/package/cryptonite
|
||||
|
||||
While cryptonite has build flags for CPU-specific features,
|
||||
there are also, in its C code, some checks of gcc defines that indicate
|
||||
specific CPU features. I found #defines checking `__SSE2__` and `__SSE4__`
|
||||
and `__AVX__` (mostly in blake2) and there might be others. That seems
|
||||
likely to be a bug in cryptonite, if its build flags are not fully
|
||||
controlling use of things like SSE.
|
||||
|
||||
I've made a change to git-annex's test suite to narrow down the problem;
|
||||
it now tests each hash individually, so you'll see which specific ones
|
||||
fail.
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://id.pvgoran.name/"
|
||||
nickname="pvgoran"
|
||||
avatar="http://cdn.libravatar.org/avatar/e32a61d9c49989ae31d7a30d6af27f5c73d8d46ba03c840a612791fe5c820b87"
|
||||
subject="comment 2"
|
||||
date="2020-03-03T02:11:30Z"
|
||||
content="""
|
||||
I run the tests on the new `master`, and I can see that all `blake2` tests (`Tests.QuickCheck.blake2s_160` and so on) fail, whereas all other hash-related QuickCheck tests succeed.
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://id.pvgoran.name/"
|
||||
nickname="pvgoran"
|
||||
avatar="http://cdn.libravatar.org/avatar/e32a61d9c49989ae31d7a30d6af27f5c73d8d46ba03c840a612791fe5c820b87"
|
||||
subject="comment 3"
|
||||
date="2020-03-03T03:16:25Z"
|
||||
content="""
|
||||
After rebuilding `cryptonite` without AES-NI support as suggested in https://github.com/haskell-crypto/cryptonite/issues/260#issuecomment-484185981 (by passing `--constraint=\"cryptonite -support_aesni\"` to `cabal install --dependencies-only` and to `cabal build`), all of QuickCheck tests pass on the machine in question. (Many other tests fail, but it's probably because I run tests from a not-yet-installed `git-annex` binary.)
|
||||
|
||||
So `cryptonite` apparently uses these AES-NI instructions (if configured to support them) without runtime checks (or at least without working runtime checks). Which constitutes a problem for any binary distributions that include `cryptonite` code: either they won't work on older CPUs, or they will not work as fast as they could on newer CPUs.
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://id.pvgoran.name/"
|
||||
nickname="pvgoran"
|
||||
avatar="http://cdn.libravatar.org/avatar/e32a61d9c49989ae31d7a30d6af27f5c73d8d46ba03c840a612791fe5c820b87"
|
||||
subject="comment 4"
|
||||
date="2020-03-03T03:19:01Z"
|
||||
content="""
|
||||
joey, can you tell what problems I will face if I run a git-annex binary with broken blake2 implementation? What functionality of git-annex will fail?
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://id.pvgoran.name/"
|
||||
nickname="pvgoran"
|
||||
avatar="http://cdn.libravatar.org/avatar/e32a61d9c49989ae31d7a30d6af27f5c73d8d46ba03c840a612791fe5c820b87"
|
||||
subject="comment 5"
|
||||
date="2020-03-03T04:16:35Z"
|
||||
content="""
|
||||
I also posted an issue for `cryptonite`: https://github.com/haskell-crypto/cryptonite/issues/314
|
||||
"""]]
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 6"""
|
||||
date="2020-03-09T19:00:35Z"
|
||||
content="""
|
||||
git-annex does not use blake2 by default. If someone has configured it to
|
||||
use blake2 (probably because they want the speed) and added some files to
|
||||
a repo, it will then use blake2 to hash those files going forward.
|
||||
|
||||
So, in balance, it seems better to disable the unsafe optimisation,
|
||||
and have it be a little bit slower, than not work on some machines.
|
||||
|
||||
Thanks for fileing the issue on cryptonite. I don't see anything further to
|
||||
be done in git-annex, so I'll close this bug now.
|
||||
"""]]
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
Attempting to build commit 7fcbb92 on Windows 7 by running "stack build" fails with the following error:
|
||||
|
||||
[[!format sh """
|
||||
[571 of 636] Compiling Utility.WebApp
|
||||
|
||||
Utility\WebApp.hs:93:17: error:
|
||||
Variable not in scope: inet_addr :: [Char] -> IO HostAddress
|
||||
|
|
||||
93 | addr <- inet_addr "127.0.0.1"
|
||||
| ^^^^^^^^^
|
||||
|
||||
Utility\WebApp.hs:96:33: error:
|
||||
Variable not in scope: aNY_PORT :: PortNumber
|
||||
|
|
||||
96 | bind sock (SockAddrInet aNY_PORT addr)
|
||||
| ^^^^^^^^
|
||||
"""]]
|
||||
|
||||
- stack version: 2.3.3
|
||||
- Windows version: Windows 7 Enterprise, version 6.1
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-10-08T14:38:26Z"
|
||||
content="""
|
||||
Those came from the network library, but were removed in network-3.0.
|
||||
|
||||
I've updated it to work with the new library.
|
||||
"""]]
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
In a repository with submodules, if I want to initialise git-annex on all submodules, I expect that `git submodule foreach git annex init` should work. Other `git-annex` commands seem to work with the `submodule foreach` command just fine.
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
1. Clone a repository with submodules (recursively): `git clone --recursive <remote>`
|
||||
2. Initialise the main repository's annex: `git annex init`
|
||||
3. Try to initialise git-annex in all submodules: `git submodule foreach git annex init`
|
||||
|
||||
This produces the following error:
|
||||
```
|
||||
git-annex: git: createProcess: runInteractiveProcess: chdir: inappropriate type (Not a directory)
|
||||
fatal: run_command returned non-zero status for scripts
|
||||
.
|
||||
```
|
||||
|
||||
As a workaround, manually changing directory into each submodule and running `git annex init` works, but there are cases where having a general script that can iterate submodules is convenient.
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
- git-annex version: 8.20201007-gcf33be21ac
|
||||
- OS: Arch Linux
|
||||
|
||||
|
||||
### 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 use it regularly with great success :)
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="kyle"
|
||||
avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
|
||||
subject="comment 1"
|
||||
date="2020-10-20T15:59:26Z"
|
||||
content="""
|
||||
I can trigger this issue on my end too (tried with
|
||||
7.20190503-g4da50456a and 8.20201008-gad86a25c5). In case it's
|
||||
helpful, here is a minimal reproducer:
|
||||
|
||||
[[!format sh \"\"\"
|
||||
set -ue
|
||||
|
||||
cd \"$(mktemp -d \"${TMPDIR:-/tmp}\"/gx-XXXXXXX)\"
|
||||
|
||||
git annex version
|
||||
pwd
|
||||
|
||||
git init src
|
||||
(
|
||||
cd src
|
||||
git init sub
|
||||
git -C sub annex init
|
||||
git -C sub commit --allow-empty -m sub-c0
|
||||
git submodule add ./sub
|
||||
git commit -m sub
|
||||
)
|
||||
|
||||
git clone --recursive src dest
|
||||
(
|
||||
cd dest
|
||||
git annex init
|
||||
git submodule foreach 'git annex init'
|
||||
)
|
||||
\"\"\"]]
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2020-10-23T16:21:12Z"
|
||||
content="""
|
||||
Let's see, sub/.git is a file not a directory, and that's what it's trying
|
||||
to chdir to, when running git.
|
||||
|
||||
fixupUnusualRepos usually converts that file to a symlink to a directory,
|
||||
but when the annex has not been initialized yet, it avoids doing so, because
|
||||
users would be unhappy if an accidential git-annex run in a submodule not
|
||||
initialized for git-annex started messing with it.
|
||||
|
||||
git-annex does not normally chdir when running git, and the only place that
|
||||
does is Config.read'. Which only does it to make git read the right config,
|
||||
for when it's reading some remote's config. So, using --git-dir there will
|
||||
have the same effect, and avoid the problem.
|
||||
|
||||
Which it did, but then there's the new problem not much further along:
|
||||
|
||||
git-annex: /home/joey/tmp/gx-KHSxawT/sub: changeWorkingDirectory: does not exist (No such file or directory)
|
||||
|
||||
This is from Git.CurrentRepo.get, which does a setCurrentDirectory.
|
||||
Where does that path that does not exist come from?
|
||||
.git/modules/sub/config has "core.worktree = ../../../sub"
|
||||
|
||||
git clone sets that. And it's a path from ../.git/modules/sub/
|
||||
back to the work tree. git-annex interprets it as relative to `GIT_DIR`,
|
||||
which git submodule sets to ".git".
|
||||
|
||||
So git-annex needs to check if .git is a gitdir: reference, and
|
||||
then interpret core.worktree relative to what it points to.
|
||||
|
||||
Or, alternatively, fixupUnusualRepos could learn to tell if the *current*
|
||||
command is git-annex init, and go ahead with the fixes. Which would avoid
|
||||
needing to chase more of this weird stuff.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
|
||||
avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
|
||||
subject="comment 3"
|
||||
date="2020-10-21T07:51:37Z"
|
||||
content="""
|
||||
Great! Thanks for checking and for the minimal reproducible example!
|
||||
"""]]
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2020-10-23T18:19:03Z"
|
||||
content="""
|
||||
Tried to implement that idea of detecting if the repo is in the process of
|
||||
initializing, but automatic initialization makes that impractical to
|
||||
implement, I think.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
|
||||
avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
|
||||
subject="comment 5"
|
||||
date="2020-10-24T14:39:38Z"
|
||||
content="""
|
||||
Awesome! Thanks for the quick response and fix Joey!
|
||||
"""]]
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
The bundle provided at https://git-annex.branchable.com/install/Linux_standalone/ doesn't work
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
1. I downloaded this file: https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz
|
||||
|
||||
2. I untared it in /usr/local and renamed the resulting directory to '/usr/local/git-annex'
|
||||
|
||||
3. I added '/usr/local/git-annex' to my PATH
|
||||
|
||||
4. I ran 'git-annex' and got:
|
||||
|
||||
mv: cannot move '/home/lyderic/.cache/git-annex/locales.tmp/ec977e22ef909b450a3a84bd55783865.1075139' to '/home/lyderic/.cache/git-annex/locales/ec977e22ef909b450a3a84bd55783865': No such file or directory
|
||||
|
||||
5. I fixed the problem by doing this:
|
||||
|
||||
$ mkdir ~/.cache/git-annex/locales
|
||||
|
||||
[[done]]
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-annex version: 8.20200909-g2d5036e44
|
||||
OS: Ubuntu 20.04.1
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
This is a transcript of the commands I ran to show and fix the bug:
|
||||
|
||||
[[!format sh """
|
||||
~$ sudo tar -xzf Downloads/git-annex-standalone-amd64.tar.gz -C /usr/local
|
||||
~$ sudo mv /usr/local/git-annex.linux /usr/local/git-annex
|
||||
~$ sudo chown -R 0.0 /usr/local/git-annex
|
||||
~$ export PATH=$PATH:/usr/local/git-annex
|
||||
~$ git-annex version
|
||||
mv: cannot move '/home/lyderic/.cache/git-annex/locales.tmp/ec977e22ef909b450a3a84bd55783865.1075139' to '/home/lyderic/.cache/git-annex/locales/ec977e22ef909b450a3a84bd55783865': No such file or directory
|
||||
~$ mkdir ~/.cache/git-annex/locales
|
||||
~$ git-annex version | head -1
|
||||
git-annex version: 8.20200909-g2d5036e44
|
||||
"""]]
|
||||
|
||||
### 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 have never used it. I am learning it / evaluating it right now. I am very impressed so far!
|
||||
|
||||
> [[fixed|done]], the bundle will be updated in the upcoming release.
|
||||
> --[[Joey]]
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
```
|
||||
chymera@silenthost /mnt/data/ni_data $ git annex direct
|
||||
[...]
|
||||
direct ofM.vta/20180730_070313_6592_1_1/8/pdata/1/reco ok
|
||||
direct ofM.vta/20180730_070313_6592_1_1/8/pdata/1/visu_pars ok
|
||||
direct ofM.vta/20180730_070313_6592_1_1/8/pulseprogram ok
|
||||
direct ofM.vta/20180730_070313_6592_1_1/8/specpar ok
|
||||
direct ofM.vta/20180730_070313_6592_1_1/8/uxnmr.info ok
|
||||
error: git-annex died of signal 11
|
||||
chymera@silenthost /mnt/data/ni_data $ git annex direct
|
||||
commit
|
||||
|
||||
^C
|
||||
```
|
||||
|
||||
I let it try to resume for a very long time (about a day) and it did nothing.
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
6.20170818 on Gentoo Linux
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
This is a fairly large repository which was only just cloned and with all data transferred (`git clone` and `git annex get .` worked fine).
|
||||
|
||||
> [[closing|done]] per my comment --[[Joey]]
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-05-04T17:01:56Z"
|
||||
content="""
|
||||
git-annex no longer supports direct mode in current versions,
|
||||
so whatever code might have caused that behavior is removed.
|
||||
|
||||
The signal 11 is, however, suprising. If a current version of git-annex
|
||||
segfaults, it would be worth filing a bug report and chasing that down,
|
||||
although only after you test your machine's memory for problems that might
|
||||
lead to a sefault.
|
||||
"""]]
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
`git annex add --largerthan=200mb` of a new file
|
||||
does not add a file that is large enough.
|
||||
|
||||
This is a reversion, introduced last year in
|
||||
[[!commit 3066bdb1fb60e80f40b5badc150fb6eb51a922bb]].
|
||||
|
||||
`git annex import /dir --largerthan=100mb` is also affected, and has an
|
||||
ugly fail mode as it tries to look up an annexed file outside the repo:
|
||||
|
||||
joey@darkstar:~/tmp/t>git annex import --largerthan=100mb ../d
|
||||
fatal: './../d/foo' is outside repository at '/home/joey/tmp/t'
|
||||
|
||||
That commit was otherwise right, eg `git-annex get --largerthan` should
|
||||
look at the size of the annexed file, not of the file on disk, which could
|
||||
be a small pointer file.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
The `--file` option doesn't work with youtube-dl downloaded content unless --fast or --relaxed are passed.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
[[!format sh """
|
||||
$ git annex addurl --file out.m4a https://www.bbc.co.uk/programmes/p08jsctb
|
||||
addurl https://www.bbc.co.uk/programmes/p08jsctb
|
||||
... (cut most youtube-dl output)
|
||||
[download] Destination: Bloodsport, Introducing Bloodsport-p08jscdd.m4a
|
||||
[download] 100% of 909.06KiB in 00:03
|
||||
[ffmpeg] Correcting container in "Bloodsport, Introducing Bloodsport-p08jscdd.m4a"
|
||||
(to Bloodsport, Introducing Bloodsport-p08jscdd.m4a) ok
|
||||
(recording state in git...)
|
||||
$ ls
|
||||
'Bloodsport, Introducing Bloodsport-p08jscdd.m4a'
|
||||
"""]]
|
||||
|
||||
Whereas I expected the created file to be 'out.m4a'.
|
||||
|
||||
However it works correctly when using --fast or --relaxed to set the URL, and then using git annex get separately:
|
||||
|
||||
[[!format sh """
|
||||
$ git annex addurl --relaxed --file out.m4a https://www.bbc.co.uk/programmes/p08jsctb
|
||||
addurl https://www.bbc.co.uk/programmes/p08jsctb (to out.m4a) ok
|
||||
(recording state in git...)
|
||||
$ ls
|
||||
out.m4a
|
||||
$ git annex get out.m4a
|
||||
get out.m4a (from web...)
|
||||
... (cut most youtube-dl output)
|
||||
[download] Destination: Bloodsport, Introducing Bloodsport-p08jscdd.m4a
|
||||
[download] 100% of 909.06KiB in 00:01
|
||||
[ffmpeg] Correcting container in "Bloodsport, Introducing Bloodsport-p08jscdd.m4a"
|
||||
ok
|
||||
(recording state in git...)
|
||||
$ ls
|
||||
out.m4a
|
||||
"""]]
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
8.20200330 (Debian sid)
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
I only recently started using the web special remote stuff, and really like it; thanks!
|
||||
|
||||
### Have you had any luck using git-annex before?
|
||||
|
||||
Yes, I've used it for several years for all sorts of things, and it just gets better and better.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
### Please describe the problem.
|
||||
|
||||
git-lfs has an aeson upper bound of < 1.5, but I have built it successfully with aeson 1.5.4
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-lfs 1.1.0 on nixos
|
||||
|
||||
|
||||
### 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 really like git-annex. Although I have to admit I am not an active user myself. I just want to keep it working for all nixos users, I know some that rely on it.
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-11-19T15:58:05Z"
|
||||
content="""
|
||||
Fixed that. Do note this is not a bug tracker for other software, even if I
|
||||
happen to have written it; you can contact me by email for git-lfs bugs.
|
||||
"""]]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
Hello,
|
||||
|
||||
I am using git annex for three years with no issues :-), but now I am facing a problem I’ve never seen before.
|
||||
|
||||
I have a repository with several annexed files since 2017. Usually, I add big files with ``git annex add`` while for regular small files, I always use a simple ``git add``.
|
||||
My problem is, now, all files added with ``git annex add`` are always considered as annexed files, which is undesirable. If I clone a new copy of the repository, ``git add`` works as expected, but from the moment I run a simple ``git annex get somefile``, all ``git add`` is executed as if it were a ``git annex add``.
|
||||
|
||||
I don't know if this is a bug or just a change in the default behavior.
|
||||
|
||||
Any idea about how to solve it?
|
||||
|
||||
Thank you
|
||||
|
||||
|
||||
Versions:
|
||||
git 2.20.1 /
|
||||
git annex 7.20190912-1 /
|
||||
ubuntu 19.10
|
||||
|
||||
> [[done]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="git add behavior"
|
||||
date="2020-03-27T20:49:19Z"
|
||||
content="""
|
||||
It's a change in default behavior, but the old default was restored in the more recent versions. (Detailed discussion [[here|forum/lets_discuss_git_add_behavior]]). Can you upgrade to the most recent version? [[install/conda]] lets you install one without being root. You might also want to set `annex.gitaddtoannex` to `false`.
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="kyle"
|
||||
avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
|
||||
subject="comment: resolved by 7.20191024"
|
||||
date="2020-03-27T20:49:44Z"
|
||||
content="""
|
||||
> git annex 7.20190912-1
|
||||
|
||||
The `git add` behavior that you describe changed in 7.20191024. The
|
||||
CHANGELOG entries under that release provide a good description of the
|
||||
current behavior.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="comment 3"
|
||||
date="2020-03-27T21:11:13Z"
|
||||
content="""
|
||||
My \"upgrade to most recent version\" advice should have mentioned that the most recent version is 8.*, which will auto-upgrade your repositories to version 8. If for whatever reason you don't want to do the upgrade right now, 7.* versions from 7.20191024 restore old behavior, as Kyle suggested. Note that if you have `annex.largefiles` configured, `git add` will add matching files to the annex, unless `annex.gitaddtoannex`.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="comment 4"
|
||||
date="2020-03-27T21:12:18Z"
|
||||
content="""
|
||||
I meant, unless `annex.gitaddtoannex=false`.
|
||||
"""]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="vinicius.vin@6d4d58c59c394cd744d469c9d7c41e264331dfcd"
|
||||
nickname="vinicius.vin"
|
||||
avatar="http://cdn.libravatar.org/avatar/b332bfc1d3f49c196e1bff84b53d0f8b"
|
||||
subject="comment 5"
|
||||
date="2020-03-27T23:04:34Z"
|
||||
content="""
|
||||
Both suggestions solve my issue.
|
||||
Thank you for the quick reply!
|
||||
"""]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="clarification re: upgrades"
|
||||
date="2020-03-30T15:24:01Z"
|
||||
content="""
|
||||
p.s. the italics in my comment re: upgrading to v8 were an accident of formatting (`7.*` / `8.*` got interpreted as italics), not some emphasis of caution about the upgrade. v8 has been working fine for me, and on this forum there has been only [[one|bugs/upgrade_to_V8_fails]] report of an issue with the upgrade, which has since been fixed. You can also guard against any possible upgrade issues by backing up `.git/annex/` (excluding `.git/annex/objects`) and git config files before the upgrade.
|
||||
|
||||
One small v8 change to note is the [more uniform handling of dotfiles](https://hackage.haskell.org/package/git-annex-8.20200226/changelog); old scripts using `--include-dotfiles` flag of `git-annex-add` would need to be updated.
|
||||
"""]]
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue