Re: The maintenance tasks will never run if maintenance.lock is accidentally not deleted

[Derrick Stolee <stolee@gmail.com>]

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@gmail.com> 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