dgit.raspbian.org Git - git-annex.git/blob

   1 [[!comment format=mdwn
   2  username="joey"
   3  subject="""comment 2"""
   4  date="2020-08-25T17:01:55Z"
   5  content="""
   6 That is the relevant commit indeed.
   7
   8 We have two different things that want to hard link a file for different
   9 purposes. The purposes are not compatible. So one of them has to win out.
  10
  11 If both annex.hardlink and annex.thin were both allowed to hard link the
  12 same file, then a file could get a link count of more than 2. That would
  13 prevent using the method that annex.thin relies on to avoid two unlocked
  14 files with the same content ending up hard linked together. With the very
  15 undesirable result that an edit to one file would also edit the other file.
  16
  17 Now, I could imagine using some other thing than link count to avoid that
  18 situation, eg keep track of when two files have the same content. But
  19 there's a second similar problem: If a file were unlocked in one repo and
  20 that repos's annex/objects also hard linked to its remote's annex/objects,
  21 then editing the file in the first repo would corrupt the object content in
  22 the other repo.
  23
  24 So I think the only other possible way for it to work would be for which
  25 ever of the two caused a hard link to be made first to win, rather than
  26 annex.thin always winning as it does now. So, after a `git annex get` in
  27 the clone hard linked the file (annex.hardlink wins), `git annex unlock`
  28 would copy the file (annex.thin loses). While a `git add` would hard link
  29 the file to annex/objects (annex.thin wins), resulting in `git annex copy
  30 --to origin` having to copy the file (annex.hardlink loses).
  31
  32 But that would not change the behavior in your test case,
  33 since it needs to get the file (annex.hardlink wins) before unlocking
  34 it (annex.thin loses).
  35
  36 So the benefit of making that change seems small to nonexistent as far as
  37 this bug report goes. Behavior becomes less consistent, it has to work
  38 harder to enforce the link count invariant, and it doesn't actually change
  39 the test case. The only real benefit would be when some files are not
  40 unlocked, but annex.thin is set, since then the locked files could be
  41 hardlinked.
  42
  43 ----
  44
  45 I added a note to the annex.hardlink docs about annex.thin winning and am
  46 inclined to only do that.
  47 """]]