"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> $ cat .git/reftable/tables.list
> -00000001-00000001.log
> -00000002-00000002.ref
> -00000003-00000003.ref
> +00000001-00000001-RANDOM1.log
> +00000002-00000002-RANDOM2.ref
> +00000003-00000003-RANDOM3.ref
> ....
> @@ -940,7 +944,7 @@ new reftable and atomically appending it to the stack:
> 3. Select `update_index` to be most recent file's
> `max_update_index + 1`.
> 4. Prepare temp reftable `tmp_XXXXXX`, including log entries.
> -5. Rename `tmp_XXXXXX` to `${update_index}-${update_index}.ref`.
> +5. Rename `tmp_XXXXXX` to `${update_index}-${update_index}-${random}.ref`.
> 6. Copy `tables.list` to `tables.list.lock`, appending file from (5).
> 7. Rename `tables.list.lock` to `tables.list`.
Is this because we have been assuming that in step 5. we can
"overwrite" (i.e. take over the name, implicitly unlinking the
existing one) the existing 0000001-00000001.ref with the newly
prepared one, which is not doable on Windows?
We must prepare for two "randoms" colliding and retrying the
renaming step anyway, so would it make more sense to instead
use a non-random suffix (i.e. try "-0.ref" first, and when it
fails, readdir for 0000001-00000001-*.ref to find the latest
suffix and increment it)?
> @@ -993,7 +997,7 @@ prevents other processes from trying to compact these files.
> should always be the case, assuming that other processes are adhering to
> the locking protocol.
> 7. Rename `${min_update_index}-${max_update_index}_XXXXXX` to
> -`${min_update_index}-${max_update_index}.ref`.
> +`${min_update_index}-${max_update_index}-${random}.ref`.
> 8. Write the new stack to `tables.list.lock`, replacing `B` and `C`
> with the file from (4).
Likewise.
