followup and retitle
This commit is contained in:
parent
470a6ec0d5
commit
7ab9f0b7d3
2 changed files with 21 additions and 0 deletions
|
@ -28,3 +28,5 @@ Clone a git annex repo on a network file system, run
|
|||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
[[!meta title="git-annex and NFS don't mix; could git annex init detect NFS and refuse to use it?"]]
|
||||
|
|
|
@ -0,0 +1,19 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2015-02-04T19:31:32Z"
|
||||
content="""
|
||||
git-annex uses posix file locking to avoid scenarios that could
|
||||
otherwise result in data loss when dropping a file.
|
||||
|
||||
This indeed involves keeping a file open and locked while removing it.
|
||||
|
||||
Since NFS's posix file locking support ranges from poor to completely
|
||||
broken, it's not wise to use git-annex over NFS at all. It's much nicer
|
||||
to use it locally, with a git remote accessing the file server over
|
||||
eg, ssh.
|
||||
|
||||
I can't see any changes to git-annex that could improve its handing
|
||||
of NFS, unless there's a good way to detect a NFS filesystem and make
|
||||
`git annex init` refuse to set up a repository there.
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue