Cannot remove .git: Directory not empty
Asked Answered
D

3

9

Unable to remove .git

I have a git repository, Rift, that I am trying to remove. On attempting to run rm -rf, I get the error: rm: cannot remove 'Rift/.git/objects/pack': Directory not empty.

When I navigate to the bottom of the directory tree, I find a hidden file, called .fuse_hidden followed by a string of numbers and letters, possibly hexadecimal. I can manually remove this file, but as soon as I remove it, another with a different string of numbers and letters appended to it is created in it's place.

I have tried rm .git/objects/pack/* && rm -rf .git, sudo rm -rf .git, chmod -w .git/objects/path and killall git, none of which have had any success.

enter image description here

Dipetalous answered 16/11, 2020 at 3:40 Comment(8)
I'm guessing you might have a process other than git that's accessing this git repo. Try to find out what is creating those files and the kill or temporarily disable that process.Wiburg
@ewong That's what im trying to do, but there's no easy way I know of of doing that... or any way at all really.Dipetalous
FUSE is the user-space file system framework. This implies your Git repository has a mount point inside it. You'll need to undo the mount.Flung
@Flung aaaaaand I don't have any extra drives, nor is it mounted. How would I go about removing that.Dipetalous
FUSE is a framework, but on Linux, you don't need to mount a device as a file system. The mount command will show the existing mounts. (Maybe your repository is under a FUSE mount, rather than containing one? Maybe the user space file system in question is misbehaving, too.)Flung
Good read: superuser.com/questions/1184998/…Ankara
@DeathWaltz: What happens if you rename .git. Do still new files mysteriously appear there by themselves?Howling
@Howling Yes.Dipetalous
I
7

You can use the fuser command.

The fuser is a command line utility intended to locate processes based on the files, directories, or a socket a particular process is accessing. It helps a system user identify processes using files or sockets.

Use the fuser command on the .git directory, to find all of the process ids which are accessing the directory.

fuser .git

Afterwards you can use the -k parameter to kill the processes, and then you should be able to delete the directory.

fuser -k .git

Importunity answered 16/11, 2020 at 14:52 Comment(5)
Do you mean fuser --kill <filename>?Dipetalous
You could do, or you can investigate using the verbose -v parameter first, and then decide.Importunity
The point of stack overflow is not only to help users with their current question, but also future users with the same question. So if you could provide that detail in your answer, that would help not only me, but future generations with similar problems.Dipetalous
This seems to have fixed it, but not totally sure. If the problem persists and this doesn't work, ill come back.Dipetalous
Closing the terminal worked for me. It killed the process that kept on writing the fuse_hidden files and I was able to rm -rf .git.Montez
D
1

Another solution I have recently found is to use the lsof command, using the afflicted filename as a parameter. For example:

#This will give you information about what process has the file open
[root@host]$ lsof .git/objects/pack/.fuse_hidden000000000f1f
#This will kill the process locking the file
[root@host]$ kill -s 9 $(lsof -t .git/objects/pack/.fuse_hidden000000000f1f)

The -t switch tells lsof to use "terse" mode, only returning the PID. This PID is then passed to kill using the -s 9 flag, meaning to send the signal "SIGKILL" instead of the default more polite request "SIGTERM" or potentially "SIGHUP"

Dipetalous answered 20/7, 2022 at 18:19 Comment(0)
A
0

Knowing what exactly is causing this specific error (gitstatusd),

you can do,

killall -15 gitstatusd-linux-x86_64

This is usually a problem with gitstatusd used by the majority of zsh themes.

Closing the terminal also works since zsh is a child process of the terminal and gitstatusd is a child process of zsh.

Abstinence answered 9/4, 2023 at 10:28 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.