Re: gc considered dangerous

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



söndag 08 februari 2009 15:56:38 skrev Johannes Schindelin:
> Hi,
> 
> On Sun, 8 Feb 2009, Robin Rosenberg wrote:
> 
> > I've seen this. Running git gc on Windows, while having Elipse open can 
> > kill your object database.
> 
> You had me really scared with the mail subject!

Losing a repo *is* scary., especially if your boss is the one losing it.
That should simply not happen unless there is a disk failure. Fortunately
I believe the two lost branches did not contain anything useful.

> > if gc doesn't find a new optimal pack it tries to rewrite a new pack 
> > with the same id. So it rm's the idx file (fine) and the the pack file 
> > (not ok) and gives up,
> 
> I disagree with your notion that it is fine to kill the existing idx file 
> until the new one has been written successfully.
Then you misunderstood me. I meant that the repack script thought
it was fine.

> My preliminary guess is that this code in pack-write.c needs to use the 
> lock file paradigm:

> 
>         if (!index_name) {
> 		[...]
>         } else {
>                 unlink(index_name);
>                 fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);
>         }

Yeah, it needs to check that it can actually delete both files before actually
doing it. Then again if it wants to replace a file with a new one just like it,
why shouldn't it just skip it. Isn't that the only case I see where we can lose
data?

GC should also notice that something is not right when there are old-files
present.

-- robin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux