# Re: get file watcher is keeping lock on files for a long time 2 messages from 2024-09-16 to 2024-09-16. Participants: Git Mailing, brian m. carlson. Thread: https://gitlist.dev/t/62124 ## Git Mailing, 2024-09-16 19:00 Subject: Re: get file watcher is keeping lock on files for a long time Message-ID: URL: https://gitlist.dev/e/CAHmn3WVakAs4XPtmvBYB4inKah0WPYACaXJGScerbVMTi4D4eA%40mail.gmail.com In-Reply-To: ``` I'm not able to delete a folder minutes after the last git operation as the git process keeps running in the background and won't stop. How can I have git stop after, say, 30 secs. of non-operation? ``` ## brian m. carlson, 2024-09-16 20:12 Subject: Re: get file watcher is keeping lock on files for a long time Message-ID: URL: https://gitlist.dev/e/ZuiRQFVHgN98qBfS%40tapette.crustytoothpaste.net In-Reply-To: ``` On 2024-09-16 at 19:00:17, Git Mailing wrote: > I'm not able to delete a folder minutes after the last git operation > as the git process keeps running in the background and won't stop. > > How can I have git stop after, say, 30 secs. of non-operation? There's not enough information here for us to give you any useful advice. First, we need to know what operating system and version you're using, since the advice we give will depend on what OS you have. For example, it's well known that Windows has a design flaw that prevents most files from being removed while they're being used. Second, we need to know the exact command line of the process that's running in the background. For example, if the process that's running is git gc, then there's an option to disable that and let you repack on your own terms. It could also be that there's a process being invoked by your editor, for example, that you might need to adjust in your editor. Determining this should be possible with `ps auxf` on Linux and it should show the processes in a tree format which will also indicate the parent process (such as an editor). As for the request to stop after 30 seconds, there is no such option. Git isn't actually doing nothing in most cases, or it would have exited already, and it would be very undesirable to have most Git operations (such as a clone) spontaneously abort after 30 seconds. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA ```