Byron
commented
4 months ago Thanks so much for reporting! I am also very sorry to see that files were deleted, and hope that these docs on data recovery with GitButler can help getting them back. Unfortunately, I don't know much about how virtual branches are applied, and can't even theorise about possible causes for the data-loss described here.
But, having recently worked on the watcher part I can say that the theory of GB causing this itself seems likely.
After all, when files are changed, it will recalculate a lot of things and read files in the process. This happens in parallel to the ongoing changes in the working tree, preventing the removal of files.
In theory, filesystem events should be bundled into 100ms time-slices, but judging from the log this doesn't really happen here as these events are apparently more frequent than that. But even if it would work, then the changing operation could still not take longer than 100ms, or else the recalculation would already kick in. And even if this window would be larger than 100ms, there is always a chance that a change takes longer than that.
The only way to truly prevent 'stepping onto ones feet' is to assure reads are never interleaved with writes, something that cannot currently be done but of course is possible.
slingshotvfx
gitbutler 0.11.3 for windows very often has issues with locked files/access denied errors on my machine. Running windows 11.
When these errors pop up, it permanently deletes the file(s) that were erroring, resulting in a loss of data.
This might be a dupe of https://github.com/gitbutlerapp/gitbutler/issues/3412, but I'm opening a new issue because I have no explorer windows, command prompts, or VS Code instances open, and file locksmith shows no handles/processes with locks on the files that show up in the error logs.
Is it possible gitbutler is locking/blocking it's own access to files somehow?
Here's an example:
deleting a branch after it's merged
In this example,
filesystem.pywas deleted and no longer exists on the disk.There might actually be two issues here. I think the
ERROR set_base_branch: crates\gitbutler-tauri\src\virtual_branches.rs:138: error=Error(failed to checkout treecall is destructively removing changed files before erroring and not putting them back. But I'm also not sure where theAccess is deniederror is coming from in the first place.I've also experienced this same issue when unapplying branches, updating the workspace, and switching back to gitbutler (after checking out the main branch elsewhere)