git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Git ML <git@vger.kernel.org>, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: gc considered dangerous
Date: Sun, 8 Feb 2009 17:04:59 +0100	[thread overview]
Message-ID: <200902081704.59439.robin.rosenberg.lists@dewire.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0902081551290.10279@pacific.mpi-cbg.de>

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

  reply	other threads:[~2009-02-08 16:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-08  2:47 gc considered dangerous Robin Rosenberg
2009-02-08 14:34 ` Robin Rosenberg
2009-02-08 14:56 ` Johannes Schindelin
2009-02-08 16:04   ` Robin Rosenberg [this message]
2009-02-08 17:18     ` Johannes Schindelin
2009-02-08 18:24     ` Steffen Prohaska
2009-02-08 19:37       ` Robin Rosenberg
2009-02-08 20:00   ` Junio C Hamano
2009-02-08 20:08     ` Robin Rosenberg
2009-02-08 20:10     ` Robin Rosenberg
2009-02-09  6:59     ` Mike Hommey
2009-02-09  7:43       ` Junio C Hamano
2009-02-08 20:09 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200902081704.59439.robin.rosenberg.lists@dewire.com \
    --to=robin.rosenberg.lists@dewire.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).