mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2014-08-16 13:52:29 -04:00
commit 153053d0cd
3 changed files with 44 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_2_e8f011263bfa4c3c3d04494ea1c88523._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="zardoz"
ip="78.48.163.229"
subject="comment 2"
date="2014-08-16T11:42:22Z"
content="""
Hm, I don’t quite follow the remark on having everything in a single
directory. Rather than saying that the relative path adds additional
entropy, what I was aiming at is the file-system cannot have two
alternate versions of one file name at the same path with the same
mtime, and that’s why it occurred to me that encoding both path and
mtime within the key doesn’t just increase the odds, but effectively
_guarantees_ that there won’t be any collisions. Does this seem to
hold up, or am I missing something? (Of course one can fudge the
mtimes, but that’s something under the user’s control.)
While a large repo with many files very likely has lots of distinct
files with identical basename, mtime (in s.) and size, all these files
with the same mtime must necessarily be located at different paths.
"""]]

15
doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_3_bda1e0d3569a6becf374d0e820219469._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="zardoz"
ip="78.48.163.229"
subject="comment 3"
date="2014-08-16T13:58:28Z"
content="""
One scenario where the above guarantee would be violated is when one
moves a new file of identical size, basename, and mtime, into a path
where a key-colliding file has been kept before. Still, I’d consider
this a scenario one could reasonably control for (especially in the
archive usecase); plus, even without manual control such a
move-induced collision would be much more unlikely than a collision of
basenames only.
"""]]

8
doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="EskildHustvedt"
ip="80.202.103.55"
subject="comment 3"
date="2014-08-16T15:22:35Z"
content="""
Ah, well then, that sounds a lot more reasonable. Though legal, I have yet to hear of a sane reason for using newlines in filenames.
"""]]