comment

2 files changed, 24 insertions, 0 deletions

diff --git a/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn
index 7abb6895d..425948efd 100644
--- a/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn
+++ b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn
@@ -1,3 +1,5 @@
 I believe cloning a repository on the same filesystem already makes use of cp --reflink=auto, but it appears that git-annex-{get,copy} use rsync even when both repositories involved in the copy/get are on the same filesystem.
 
 Would it be possible for git-annex-get and git-annex-copy to use cp --reflink=auto when the source and destination repositories are on the same filesystem?
+
+[[!meta title="allow remotes to do their own, smarter diskreserve checking"]]
diff --git a/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment
new file mode 100644
index 000000000..92766fc27
--- /dev/null
+++ b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-07-19T14:57:14Z"
+ content="""
+Yes, reflink is used instead of rsync when it's able to determine it's the
+same filesystem.
+
+Not checking diskreserve for reflink (and also for hard link when
+annex.hardlink is set) would be nice. But, it's a layering problem
+since currently the diskreserve check is done separately from the transfer.
+
+The same layering problem also makes downloads from encrypted special
+remotes not check if there's space for both the encrypted and de-encrypted
+file content, in cases where both files are present on disk at the same
+time.
+
+So, there would be multiple benefits to improving the api somehow so more
+smart diskreserve checks can be done. Although I'd then worry that if
+remotes were responsible for doing diskreserve checks, they might be buggy
+and forget to check. 
+"""]]