response
authorJoey Hess <joeyh@joeyh.name>
Thu, 10 Dec 2015 15:20:01 +0000 (11:20 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 10 Dec 2015 15:20:01 +0000 (11:20 -0400)
doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment [new file with mode: 0644]

diff --git a/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment b/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment
new file mode 100644 (file)
index 0000000..c0b3af0
--- /dev/null
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 32"""
+ date="2015-12-10T15:15:42Z"
+ content="""
+@openmedi git-annex doesn't currently keep track of how much space it's
+using on a special remote. It's actually quite a difficult problem to do
+that in general, since multiple distributed clones of a repository can be
+uploading to the same special remote at the same time.
+
+If it runs out of space and transfers fail, git-annex will handle the
+failures semi-gracefully, which is to say nothing will stop it from trying
+again or trying to send other data, but it will certianly be aware that
+files are not reaching the special remote.
+
+If a particular storage service has a way to check free space, it would not
+be hard to make git-annex's special remote implementation check it and
+avoid trying transfers when it's full.
+"""]]