diff options
Diffstat (limited to 'doc/bugs')
-rw-r--r-- | doc/bugs/S3_memory_leaks/comment_3_5e9cecb0e2ec7602963406779b6e3c1f._comment | 12 | ||||
-rw-r--r-- | doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn | 57 |
2 files changed, 69 insertions, 0 deletions
diff --git a/doc/bugs/S3_memory_leaks/comment_3_5e9cecb0e2ec7602963406779b6e3c1f._comment b/doc/bugs/S3_memory_leaks/comment_3_5e9cecb0e2ec7602963406779b6e3c1f._comment new file mode 100644 index 000000000..a7bb0265f --- /dev/null +++ b/doc/bugs/S3_memory_leaks/comment_3_5e9cecb0e2ec7602963406779b6e3c1f._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.112" + subject="comment 3" + date="2014-08-02T23:08:44Z" + content=""" +hS3's author seems to have abandoned it and it has other problems. I should try to switch to a different S3 library. + +There is now a workaround; S3 special remotes can be configured to use [[chunking]]. A max of one chunk will then be buffered in memory at a time. + +For example, to reconfigure an existing mys3 remote: `enableremote mys3 chunk=1MiB` +"""]] diff --git a/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn b/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn new file mode 100644 index 000000000..e41220114 --- /dev/null +++ b/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn @@ -0,0 +1,57 @@ +### Please describe the problem. + +While the docs say that WORM keys are a function of a files basename, +when doing «git annex add .», the generated keys will actually contain +the relative path (with slashes escaped). Not sure whether this is by +design or a bug in its own right. I suppose that to minimize the chance +of collisions on WORM, having the path within the key is preferable. + +A problem about this, however, is that the path in the key is not +stable, but varies with the working dir when doing the «git annex +add». So, when a file is added from one working dir (say, the repo +base), later unlocked, and readded from another working dir (say, +somewhere below the repo base), this will generate a different key +even when the file has not been touched. + +Is there a rationale for this variability, or should «add» canonicalize +the encoded paths to the repo root? + + +### What steps will reproduce the problem? + + +[[!format sh """ + +# Init +$ git init /tmp/foo +$ cd /tmp/foo && git annex init + +$ mkdir baz +$ touch baz/quux + +# Add file with working dir at repo root. +$ git annex add --backend=WORM baz +$ git commit -m "first" + +# Key includes relative path. +$ readlink baz/quux +../.git/annex/objects/8x/8V/WORM-s0-m1406981486--baz%quux/WORM-s0-m1406981486--baz%quux + +# Unlock and readd with working dir at path below repo root. +$ cd baz +$ git annex unlock quux + +$ git annex add quux +$ git com -m "second" + +# Relative path is anchored to working dir instead of repo root. +$ readlink quux +../.git/annex/objects/9G/72/WORM-s0-m1406981486--quux/WORM-s0-m1406981486--quux + +# End of transcript or log. +"""]] + +### What version of git-annex are you using? On what operating system? +Linux 3.15.8 + +git-annex 5.20140716 |