merge
This commit is contained in:
parent
be8589d5e9
commit
41a5c47860
3 changed files with 19 additions and 0 deletions
|
@ -192,3 +192,7 @@ drop file1 ok
|
|||
|
||||
[[!meta author=yoh]]
|
||||
[[!tag projects/datalad]]
|
||||
|
||||
> merged with
|
||||
> <https://git-annex.branchable.com/bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/>
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,13 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2020-03-02T19:56:49Z"
|
||||
content="""
|
||||
Sure, some minor change in git-annex could tickle non-deterministic
|
||||
behavior, eg something to do with timing of when it deletes the file
|
||||
vs the later closing of the file that drops the lock.
|
||||
|
||||
That regression made git-annex init fail when NFS doesn't have posix lock
|
||||
support enabled. It can detect that, and enables pidlock, but it can't
|
||||
detect NFS when it is pretending to support posix locks.
|
||||
"""]]
|
|
@ -30,3 +30,5 @@ Clone a git annex repo on a network file system, run
|
|||
"""]]
|
||||
|
||||
[[!meta title="git-annex and NFS don't mix; could git annex init detect NFS and refuse to use it?"]]
|
||||
|
||||
[[!tag projects/datalad]]
|
||||
|
|
Loading…
Reference in a new issue