This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb.git hiccup
Christopher Faylor wrote:
> On Sun, Oct 04, 2009 at 05:05:02PM +0200, Jim Meyering wrote:
>>Christopher Faylor wrote:
>>
>>> On Sun, Oct 04, 2009 at 08:51:32AM +0200, Jim Meyering wrote:
>>>>But when I tried to diagnose it, I discovered that there are unreadable
>>>>temporary pack files owned by from back in February that prevent a local clone.
>>>>
>>>> sourceware$ cd /git/archer.git/objects; ls -l tmp*
>>>> -rw------- 1 rmoseley archer 368640 Feb 9 2009 tmp_pack_hMUtoO
>>>> -rw------- 1 rmoseley archer 876544 Feb 9 2009 tmp_pack_jmBcho
>>>> -rw------- 1 rmoseley archer 1007616 Feb 9 2009 tmp_pack_zbwx0m
>>>>
>>>>I have neither root access nor archer group membership, so cannot remove
>>>>them, and sent a request to overseers yesterday. No reply yet.
>>>
>>> How did rmosely manage to create these files when he does not have
>>> login privileges?
>>
>>Via git.
>>tmp_pack_ files are created by git, but obviously not always
>>removed by the version of git that was running back then.
>>rmosely *does* have write access to the archer git repository.
>>
>>> Do we need to close a hole here somewhere?
>>
>>It'd be good to make sure that can't happen again,
>>but it's not a security problem (DoS, maybe, though)
>
> Ok, so what's the solution? Should a cron job be cleaning out old tmp*
> files or is this no longer an issue with newer versions of git?
I've poked around a little and see that this has been
reported to happen upon write (e.g., disk full) errors.
The fact that they'd been there for months without
causing trouble suggests that they impede local cloning only,
and not cloning via any server, so I wouldn't worry about it.