Loose object tempfile failure on Windows

[jpgrayson]

Duplicates

• I have searched the existing issues

Current behavior 😯

On Windows in an Msys2 environment, I am observing a failure behavior when attempting to write an already existing loose object. This can happen, for example, when programmatically creating trees where sometimes the empty tree (which has the magic hash 4b825dc642cb6eb9a060e54bf8d69288fbee4904) emerges repeatedly.

The crux of the problem seems to be how tempfile::NamedTempFile does its persist(). In this Windows environment, an access/permission denied error occurs during persist() when the target path already exists.

LooseWrite(Persist { source: PersistError(Os { code: 5, kind: PermissionDenied, message: "Access is denied." }), target: ".\\.git\\objects\\4b\\825dc642cb6eb9a060e54bf8d69288fbee4904" })'

Another thing I'm noticing is that gix-odb seems to create objects with a different set of permissions than git does, i.e. gix makes object files -rw------- whereas objects files created by git are -r--r--r--. While I do not think this is necessarily a cause for this issue, it does seem to highlight a potential deficiency.

Expected behavior 🤔

It remains a little fuzzy to me as to exactly what should happen in this circumstance. If we assume that hash collisions never happen, the we could potentially choose to simply ignore this kind of access denied error when attempting to create a loose object that already exists.

Or if we want to embrace the possibility of hash collisions, then I could conceive of gix-odb explicitly checking whether the existing loose object file is identical to the one being created. I'll note that outside of this Windows environment, if there were a hash collision, the new object will currently just silently win.

Yet another possibility would be to require the gix API user to pre-check whether the odb already contains any of the objects being created. This approach feels needlessly cumbersome.

Lastly, I'm no Windows expert and maybe there is something I don't understand about this environment and I'm just "holding it wrong". For context, I'm attempting to get StGit running on Windows and this problem breaks StGit's stack metadata initialization (i.e. this is blocking StGit from doing pretty much anything else).

Steps to reproduce 🕹

This is a minimal program that can reproduce the problem. Running this program twice in an otherwise empty repo will trigger the problem (panic) on the second run.

fn main() {
    let repo: gix::Repository = gix::ThreadSafeRepository::discover_with_environment_overrides(".")
        .unwrap()
        .into();
    let empty_tree = gix::objs::Tree { entries: vec![] };
    dbg!(repo.write_object(empty_tree).unwrap());
}

Unfortunately, I am only able to trigger the issue in this Windows environment. I was unable to reproduce the problem in a Linux environment.

[Byron]

Thanks a lot for the detailed writeup and analysis of the problem!

I will see how git handles it and come up with a solution that won't affect performance or usability of the API.

Edit: I forgot to say that the permissions are also to be fixed - this stems from the fact that it just does a rename of a tempfile, but it should follow that up with a chmod which maybe is what git does as well.e