On 9/23/24 6:26 AM, 刘钟博 wrote: > Thank you for your response. > On Thu, Sep 19, 2024 at 8:56 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: >> At least, I haven't been able to find a reason why Git would be >> failing with something like a segfault which would also cause leftover >> .lock files. > Yes, it is not necessarily a problem caused by git failure. I think it > is a natural > shortcoming of file existence lock, which cannot guarantee that the lock will be > released when the process exits abnormally. > >> I can speak from experience of previously having a lock timeout >> that this could cause problems where maintenance processes start >> running on the same repo concurrently. >> [1] https://github.com/microsoft/git/pull/598 > I read your commit and explored more. Perhaps the file locks provided by the > systems are a better choice, such as fcntl() on POSIX and LockFileEx() > on Windows. > They can be automatically released when the process exits abnormally. > If there are > no objections, I'll give it a try and send a patch in a few days. I'm curious to see how this would be implemented across platforms. I think the maintenance.lock file is a particular case where such a change would be welcome, because we are not writing to it and then doing a rename over the non-.lock version (like we do with many other files). For that reason, you would be creating a new API construct, not replacing the existing lockfile API. Thanks, -Stolee
