Been testing this out. If I make a local git repo, everything seems fine, but if I clone a remote repo, and try to use it I get an error:

(in a Windows command window)

> git clone https://server/git/git_bug_test
> cd git_bug_test
> git-bug user create
Name [me]:
Email [me@fake.com]:
Avatar URL:

bbc5207b0d2ddb8b823d53052a3a77eafc996a03143c3bed99f5841c2438e921

> git-bug add -t "First Bug" -m "Bug number one!"
Error: rename E:\temp\git_bug_test\.git\objects\pack\tmp_obj_2131903459 E:\temp\git_bug_test\.git\objects\e6\9de29bb2d1d6434b8b29ae775ad8c2e48c5391: Access is denied.

I can manually edit/rename the mentioned files just fine, no locks or access limits, so maybe it something else throwing the error with a spurious message?

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

sudoforge removed label lifecycle/stale 1 year ago

sudoforge added label kind/bug 1 year ago

sudoforge added label area/bugs 1 year ago

sudoforge added label priority/awaiting-more-evidence 1 year ago

sudoforge added label triage/needs-information 1 year ago

Also seeing this on Windows. Possibly related to #809 ? i.e. access is denied because Windows considers the file in use?

Also seeing this on Windows. Possibly related to #809 ? i.e. access is denied because Windows considers the file in use?

This seems unrelated to #809, which is focused on the use of parallelization in tests and cleaning up some temporary files created during the tests.

Can you provide more information about your environment when encountering this issue? Do you have the repository open in multiple windows, for example? Are you using Command Prompt, PowerShell, Git Bash (cygwin), or WSL2?

I see the same issue, when trying to add bugs to an existing git repo. Environment: Windows 10, Powershell 5.1.22621.3958

Steps to reproduce

mkdir test_repo
git init
New-Item .gitignore
git add .\.gitignore
git commit -m 'add: .gitginore'
git bug user create
git bug add -t 'testbug' -m 'description' 
 

Result:

Error: rename C:\Users\<myusername>\test_repo\.git\objects\pack\tmp_obj_3021921222 C:\Users\<myusername>\test_repo\.git\objects\e6\9de29bb2d1d6434b8b29ae775ad8c2e48c5391: Access is denied. 

The reason is that the files in objects are write-protected since they should never be modified by design of git.

However, when i initialize an empty repo and add a bug first before doing any other commits, this seems to work fine:

mkdir test_repo2
cd test_repo2
git init
git bug user create
git bug add -t 'title' -m 'description'
>fb67815 created
New-Item .gitignore
git commit -m 'add: .gitginore'
git bug add -t 'title2' -m 'description2'
>1bbb20e created

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/stale 10 months ago

sudoforge removed label lifecycle/idle 7 months ago

I have the same problem in Windows 11

The reason is that the files in objects are write-protected since they should never be modified by design of git.

Is it okay to mess with files like this? I thought that this tool could be cleanly integrated into a git environment.

I want to use this tool but if it is going to clash with git in some way, I'm not really sure if I should use it.

sudoforge changed the title from Windows: "access denied" when creating a bug to Windows: "access denied" when creating a bug 7 months ago

sudoforge removed label priority/awaiting-more-evidence 7 months ago

sudoforge removed label triage/needs-information 7 months ago

sudoforge added label priority/backlog 7 months ago

sudoforge added label triage/accepted 7 months ago

sudoforge added label platform/windows 7 months ago

Is it okay to mess with files like this? I thought that this tool could be cleanly integrated into a git environment. I want to use this tool but if it is going to clash with git in some way, I'm not really sure if I should use it.

git-bug shouldn't ever attempt to touch objects that it didn't create. so if the "safety" you're thinking of is related to your working tree and/or normal git commits and objects, yes, git-bug is safe.

regarding this issue:

as of v0.8.1, the "create a new bug" workflow is pretty simple. it handles a bit of logic like getting and cleaning up the title and body, and then calls a go-git method to handle the actual object creation.

so, i think this is likely to be a go-git issue. i found this issue, which seems to be directly related: https://github.com/go-git/go-git/issues/55. unfortunately, it doesn't have a linked commit indicating it was resolved (it was just closed due to inactivity).

it appears that a workaround might be to use "git bash", but that obviously isn't ideal if you're used to powershell and want to keep using it.

i don't have a windows machine (physical or virtual) to recreate this issue, so unfortunately, i can't really debug or iterate on go-git's internals to work out a fix at the moment.

@MichaelMure do you have any insight to add here? i think a viable workaround in the short term to unblock users would be to call the git command line for this (on windows only, as in, a separate func with a //go:build windows directive).

Thank you for your quick response !

it https://github.com/src-d/go-git/issues/1155 that a workaround might be to use "git bash", but that obviously isn't ideal if you're used to powershell and want to keep using it.

I tried this but I get this error

[13192:0511/212303.491:ERROR:service_worker_storage.cc(2072)] Failed to delete the database: Database IO error
Error: rename C:\Users\jguti\suite-cupones\.git\objects\pack\tmp_obj_3190080821 C:\Users\jguti\suite-cupones\.git\objects\e6\9de29bb2d1d6434b8b29ae775ad8c2e48c5391: Access is denied.

This same error appears in PowerShell7

This line is new:

[13192:0511/212303.491:ERROR:service_worker_storage.cc(2072)] Failed to delete the database: Database IO error

It did not appear this first time...

I have the same problem in Windows 11

...that I got the error, so that maybe there is a problem in my end unrelated to this issue.

i don't have a windows machine (physical or virtual) to recreate this issue, so unfortunately, i can't really debug or iterate on go-git's internals to work out a fix at the moment.

Maybe if it is a quick test and not too complicated I could do it for you? Dumb suggestion I guess.

Maybe if it is a quick test and not too complicated I could do it for you?

it'd likely involve running delve to debug code while modifying git-bug and go-git, recompiling, and re-running. not something i'd deem as "quick", necessarily :P

the offer is appreciated, though! i do have a windows license from a few years ago when i set up a VM for testing some things (unrelated to git-bug), so i'll dig that up at some point and get a VM rolling again.

could you test again in the WSL and let me know if you still get that issue? this is technically a linux VM so i'm not expecting you to, but am rather curious if it would be a viable workaround for people experiencing this (which i assume is likely all windows users).

it'd likely involve running delve to debug code while modifying git-bug and go-git, recompiling, and re-running. not something i'd deem as "quick", necessarily :P

Not really my definition of "quick" :S

I did the test and it worked. Apparently, creating a first bug using WSL "unlocks" the creation of bugs the normal way. These are the details:

I installed WSL and the archlinux distro. I installed git-bug manually with AUR (I did a fix stated in the comments here to be able to install it). I cloned my project repo from GitHub into the archlinux filesystem, tried to create a bug and it succeeded.

I also tried to create a bug directly in the cloned version of my repo in the windows filesystem, where I always work, and this succeeded too. I used WSL here.

Then I tried to create a bug using Git Bash and PowerShell7 directly and it worked.

I created a few more bugs and they were created without problems.

I tried both termui and webui.

I'm still getting this error... [6516:0511/232729.476:ERROR:service_worker_storage.cc(2072)] Failed to delete the database: Database IO error ...so that I think that this is not related to the issue. Probably this is due to some "tweaks" I was doing in my machine.

I didn't do further tests because I really don't now how to use this tool properly. If you want me to make some specific tests I could try to do it.

[6516:0511/232729.476:ERROR:service_worker_storage.cc(2072)] Failed to delete the database: Database IO error

sorry, can you clarify when you're seeing this? is this showing on the command line? in the browser console? somewhere else?

Then I tried to create a bug using Git Bash and PowerShell7 directly and it worked.

i'm going to write this behavior off as some ✨ windows magic ✨. i won't forget to test this some time $LATER when i set up a windows VM.

it appears that a workaround might be to use "git bash", but that obviously isn't ideal if you're used to powershell and want to keep using it.

I can confirm that using git bash does not solve the issue on Windows 11. (Neither does using git-bug termui nor webui for creating a first bug but I assume this was expected)

If you have any more ideas for workarounds on Windows which do not involve setting up WSL I volunteer to try them.

If you have any more ideas for workarounds on Windows which do not involve setting up WSL I volunteer to try them.

if you are unable or unwilling to install the WSL (which appears to be a valid workaround based on this thread), the best i can do for you is to dig up my windows key and get a VM set up for recreating and iteratively debugging this. i'm not familiar enough with windows to take a blind stab at debugging this on another platform.

i can't provide a timeline for doing this right now -- it might be this week, it might be next month, and it could be (but i'd be surprised) if it were even later.

if you are not comfortable with golang, this isn't likely to be something easy for you to take on -- but if you are, i'd welcome the support :)

sorry, can you clarify when you're seeing this? is this showing on the command line? in the browser console? somewhere else?

I'm seeing this in my terminal emulator after creating a bug and exiting the termui. My default git editor is VSCode.

But I'm testing right now and the error is not showing, I'm instead getting this error after pressing n for creating a new bug and the editor opening up.

[main 2025-05-12T11:05:47.448Z] update#setState idle
[7508:0512/070549.969:ERROR:jump_list.cc(300)] Failed to append custom category 'Recent Folders & Workspaces' to Jump List due to system privacy settings.
[main 2025-05-12T11:05:49.983Z] updateWindowsJumpList#setJumpList unexpected result: customCategoryAccessDeniedError
[main 2025-05-12T11:06:17.462Z] update#setState checking for updates
[main 2025-05-12T11:06:17.631Z] update#setState idle

I did nothing for some minutes after the editor appearing.

Then, when I write the message and close the editor I'm getting this message

[main 2025-05-12T11:07:00.047Z] Extension host with pid 9544 exited with code: 0, signal: unknown.

I tried changing the editor to notepad and now I got no messages so that I think that this is just a problem with my "tweaks".

I installed a program called UniGetUI which allowed me to update a lot of packages automatically, I think that this is what is causing the issue.

Most certainly this has nothing to do with git-bug itself, I just report it because it happened in the context of this issue.

However, when i initialize an empty repo and add a bug first before doing any other commits, this seems to work fine:

Regarding this issue, I also want to say that I tried this and it worked

@JoacoG i'm not sure what the exact source of the various messages you're getting are, but they definitely are not from git-bug. the service worker error is most likely from electron (and thus, vscode).

However, when i initialize an empty repo and add a bug first before doing any other commits, this seems to work fine:

Regarding this issue, I also want to say that I tried this and it worked

yes -- the original comment on this issue states that initializing git-bug in a brand new repository did not result in the error.

the original comment on this issue states that initializing git-bug in a brand new repository did not result in the error.

To be more specific, it was a locally created repo that was fine. A remote repo, even a newly created empty one, threw the error.

Wondering if it's running into an issue of Windows being more strict in what you can do with an open file. *nix allows you to rename an open file, Windows won't (this is one of the reasons Windows updates often require a full reboot). If that's the case, stepping through with a debugger and checking what has the file open (stale file handle waiting to be GC'd?) might give a hint even on a non-Windows install.

(thanks all for looking into this, I know what a pain it is debugging on a system you don't use)

I really don't know what's going on but I did other tests.

I see the same issue, when trying to add bugs to an existing git repo. Environment: Windows 10, Powershell 5.1.22621.3958

Steps to reproduce

mkdir test_repo
git init
New-Item .gitignore
git add .\.gitignore
git commit -m 'add: .gitginore'
git bug user create
git bug add -t 'testbug' -m 'description' 

I did something similar to this but I used touch instead of New-Item. I'm using PowerShell7. This allowed me to create a first bug

(1)

mkdir test_repo
cd test_repo
git init
touch .gitignore
git add .\.gitignore
git commit -m 'add: .gitginore'
git bug user new
          ...CREATE THE USER...
git bug user adopt [HASH]
git bug termui
          ...CREATE THE BUG...

I also tested with Git Bash and it worked.

I also tried to create an empty repo and clone it in my machine, Then I did (1) but beginning in the line below git init, and I was able to create a first bug too.

Now, about further bugs creations. I tried to add a file manually (test.txt) in both cases, then add, commit and create a bug. In the first case (local repo) I was able to create the second bug, but in the second case (empty cloned repo from github) I got the error. NOTE: I then tried this a second time and in both cases I was able to create the bug, I don't know what I did differently in the empty repo case

I also tried to use New-Item in the local repo test, add, commit and create a third bug and this succeeded too.

I really don't have much technical knowledge here, so that I cannot analyze this thoroughly, I even don't know if this is helpful, I hope it is.

@blumf yes, some windows behavior like that is likely to be the root cause here, and if so, we'd find this deeper within go-git (when it's actually creating the pack and object). nothing grabbed my attention yesterday when i stepped through the git-bug-bug-new workflow, but i could have missed something, as i'm not intimately familiar with the library yet (my existing usage of go-git has left me somewhat frustrated by its divergence from git's own behaviors, and puzzled at why golang doesn't have a better libgit2 module).

i was able to locate the windows license i used a handful of years ago (yay password managers, even if you do forget the item name). i'm going to bump up the priority on this, since it's a blocking issue for windows users. i'll be looking into this issue over the next week and will hopefully come back to this issue with much more (useful) information (and a fix).

sudoforge removed label priority/backlog 7 months ago

sudoforge added label priority/important-soon 7 months ago