{"thread":{"id":"17652","subject":"gc considered dangerous","startedAt":"2009-02-08T02:47:25Z","lastAt":"2009-02-09T07:43:00Z","messageCount":13,"participants":["Robin Rosenberg","Johannes Schindelin","Steffen Prohaska","Junio C Hamano","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"103745","messageId":"200902080347.25970.robin.rosenberg.lists@dewire.com","threadId":"17652","inReplyTo":null,"subject":"gc considered dangerous","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T02:47:25Z","receivedAt":"2009-02-08T02:47:25Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nI've seen this. Running git gc on Windows, while having Elipse open can kill your\nobject database. \n\nEclipse keeps the pack files open most of the time. Then you \nlaunch git gui which recommends the user to do a git gc. I never\ndo (it *always* wants to do this), so I haven't encountered the \nissue, but if gc doesn't find a new optimal pack it tries to rewrite a \nnew pack with the same id. So it rm's the idx file (fine) and the the\npack file (not ok) and gives up, which means it has a .pack file with \nno index, so it cannot use it. Trying git gc again after eclipse exits \nwill execute the final stab on your objects. \n\nThe underlying bug is ofcource that Windows locks files when\nthey are open. A *nix* user does not suffer from this problem.\n\nI'll investigate more at some other time. This is a preliminary\nanalysis.\n\n-- robin\n"},{"id":"103746","messageId":"200902081534.20854.robin.rosenberg.lists@dewire.com","threadId":"17652","inReplyTo":"200902080347.25970.robin.rosenberg.lists@dewire.com","subject":"Re: gc considered dangerous","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T14:34:20Z","receivedAt":"2009-02-08T14:34:20Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 februari 2009 03:47:25 skrev Robin Rosenberg:\n> \n> I've seen this. Running git gc on Windows, while having Elipse open can kill your\n> object database. \n> \n> Eclipse keeps the pack files open most of the time. Then you \n> launch git gui which recommends the user to do a git gc. I never\n> do (it *always* wants to do this), so I haven't encountered the \n> issue, but if gc doesn't find a new optimal pack it tries to rewrite a \n> new pack with the same id. So it rm's the idx file (fine) and the the\n> pack file (not ok) and gives up, which means it has a .pack file with \n> no index, so it cannot use it. Trying git gc again after eclipse exits \n> will execute the final stab on your objects. \n> \n> The underlying bug is ofcource that Windows locks files when\n> they are open. A *nix* user does not suffer from this problem.\n> \n> I'll investigate more at some other time. This is a preliminary\n> analysis.\n\nA receipe for triggering is available at http://code.google.com/p/msysgit/issues/detail?id=189\n\n-- robin\n"},{"id":"103756","messageId":"alpine.DEB.1.00.0902081551290.10279@pacific.mpi-cbg.de","threadId":"17652","inReplyTo":"200902080347.25970.robin.rosenberg.lists@dewire.com","subject":"Re: gc considered dangerous","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-08T14:56:38Z","receivedAt":"2009-02-08T14:56:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 8 Feb 2009, Robin Rosenberg wrote:\n\n> I've seen this. Running git gc on Windows, while having Elipse open can \n> kill your object database.\n\nYou had me really scared with the mail subject!\n\n> if gc doesn't find a new optimal pack it tries to rewrite a new pack \n> with the same id. So it rm's the idx file (fine) and the the pack file \n> (not ok) and gives up,\n\nI disagree with your notion that it is fine to kill the existing idx file \nuntil the new one has been written successfully.\n\nMy preliminary guess is that this code in pack-write.c needs to use the \nlock file paradigm:\n\n if (!index_name) {\n\t\t[...]\n } else {\n unlink(index_name);\n fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n }\n\nCiao,\nDscho\n"},{"id":"103758","messageId":"200902081704.59439.robin.rosenberg.lists@dewire.com","threadId":"17652","inReplyTo":"alpine.DEB.1.00.0902081551290.10279@pacific.mpi-cbg.de","subject":"Re: gc considered dangerous","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T16:04:59Z","receivedAt":"2009-02-08T16:04:59Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 februari 2009 15:56:38 skrev Johannes Schindelin:\n> Hi,\n> \n> On Sun, 8 Feb 2009, Robin Rosenberg wrote:\n> \n> > I've seen this. Running git gc on Windows, while having Elipse open can \n> > kill your object database.\n> \n> You had me really scared with the mail subject!\n\nLosing a repo *is* scary., especially if your boss is the one losing it.\nThat should simply not happen unless there is a disk failure. Fortunately\nI believe the two lost branches did not contain anything useful.\n\n> > if gc doesn't find a new optimal pack it tries to rewrite a new pack \n> > with the same id. So it rm's the idx file (fine) and the the pack file \n> > (not ok) and gives up,\n> \n> I disagree with your notion that it is fine to kill the existing idx file \n> until the new one has been written successfully.\nThen you misunderstood me. I meant that the repack script thought\nit was fine.\n\n> My preliminary guess is that this code in pack-write.c needs to use the \n> lock file paradigm:\n\n> \n> if (!index_name) {\n> \t\t[...]\n> } else {\n> unlink(index_name);\n> fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n> }\n\nYeah, it needs to check that it can actually delete both files before actually\ndoing it. Then again if it wants to replace a file with a new one just like it,\nwhy shouldn't it just skip it. Isn't that the only case I see where we can lose\ndata?\n\nGC should also notice that something is not right when there are old-files\npresent.\n\n-- robin\n"},{"id":"103761","messageId":"alpine.DEB.1.00.0902081815170.10279@pacific.mpi-cbg.de","threadId":"17652","inReplyTo":"200902081704.59439.robin.rosenberg.lists@dewire.com","subject":"Re: gc considered dangerous","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-08T17:18:26Z","receivedAt":"2009-02-08T17:18:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 8 Feb 2009, Robin Rosenberg wrote:\n\n> söndag 08 februari 2009 15:56:38 skrev Johannes Schindelin:\n> \n> > On Sun, 8 Feb 2009, Robin Rosenberg wrote:\n> > \n> > > I've seen this. Running git gc on Windows, while having Elipse open \n> > > can kill your object database.\n> > \n> > You had me really scared with the mail subject!\n> \n> Losing a repo *is* scary., especially if your boss is the one losing it. \n> That should simply not happen unless there is a disk failure. \n> Fortunately I believe the two lost branches did not contain anything \n> useful.\n\nIf you care about your data, you don't use Windows, IMHO.\n\n> > > if gc doesn't find a new optimal pack it tries to rewrite a new pack \n> > > with the same id. So it rm's the idx file (fine) and the the pack \n> > > file (not ok) and gives up,\n> > \n> > I disagree with your notion that it is fine to kill the existing idx \n> > file until the new one has been written successfully.\n>\n> Then you misunderstood me. I meant that the repack script thought it was \n> fine.\n> \n> > My preliminary guess is that this code in pack-write.c needs to use the \n> > lock file paradigm:\n> \n> > \n> > if (!index_name) {\n> > \t\t[...]\n> > } else {\n> > unlink(index_name);\n> > fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n> > }\n> \n> Yeah, it needs to check that it can actually delete both files before \n> actually doing it.\n\nNope. It needs to avoid unlinking until it knows what it did was fine.\n\n> Then again if it wants to replace a file with a new one just like it, \n\nIt might have the same name, but that does not mean that it is bytewise \nidentical. The name depends on the uncompressed objects.\n\n> Isn't that the only case I see where we can lose data?\n\nNo, you said so yourself: Eclipse prevents the pack from being deleted. \nThere are a gazillion idiotic programs on Windows who think they should \nlock random files.\n\nSo you could hit the very same issue even if your repository has twenty \npacks, and therefore could do with some gc'ing.\n\nCiao,\nDscho"},{"id":"103767","messageId":"BD926B5C-60C2-4A62-9BBC-E31CB26B9BAC@zib.de","threadId":"17652","inReplyTo":"200902081704.59439.robin.rosenberg.lists@dewire.com","subject":"Re: gc considered dangerous","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2009-02-08T18:24:33Z","receivedAt":"2009-02-08T18:24:33Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Feb 8, 2009, at 5:04 PM, Robin Rosenberg wrote:\n\n> söndag 08 februari 2009 15:56:38 skrev Johannes Schindelin:\n>> Hi,\n>>\n>> On Sun, 8 Feb 2009, Robin Rosenberg wrote:\n>>\n>>> I've seen this. Running git gc on Windows, while having Elipse \n>>> open can\n>>> kill your object database.\n>>\n>> You had me really scared with the mail subject!\n>\n> Losing a repo *is* scary., especially if your boss is the one losing \n> it.\n> That should simply not happen unless there is a disk failure. \n> Fortunately\n> I believe the two lost branches did not contain anything useful.\n\n\nIf you have a backup of the corrupted repository right after it got\ncorrupted, you can create an index by running \"git index-pack\" on\nthe pack that is lacking an index. This might rescue the lost\nbranches.\n\n\tSteffen\n"},{"id":"103772","messageId":"200902082037.54042.robin.rosenberg.lists@dewire.com","threadId":"17652","inReplyTo":"BD926B5C-60C2-4A62-9BBC-E31CB26B9BAC@zib.de","subject":"Re: gc considered dangerous","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T19:37:53Z","receivedAt":"2009-02-08T19:37:53Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 februari 2009 19:24:33 skrev Steffen Prohaska:\n> If you have a backup of the corrupted repository right after it got\n> corrupted, you can create an index by running \"git index-pack\" on\n> the pack that is lacking an index. This might rescue the lost\n> branches.\n\nYep, but the problem was that git gc was run again on the corrupted repo\nso there was only the idx left. (L)Users...\n\nCouldn't we make repack refuse to repack if it discovered left-overs from\na failed repack, or at least make it use the old pack files as reference instead\nof ignoring them? Leaving too many objects is, after all, much better than\ndestroying the repo.\n\n-- robin\n"},{"id":"103775","messageId":"7vhc34y9za.fsf@gitster.siamese.dyndns.org","threadId":"17652","inReplyTo":"alpine.DEB.1.00.0902081551290.10279@pacific.mpi-cbg.de","subject":"Re: gc considered dangerous","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-08T20:00:57Z","receivedAt":"2009-02-08T20:00:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> My preliminary guess is that this code in pack-write.c needs to use the \n> lock file paradigm:\n>\n> if (!index_name) {\n> \t\t[...]\n> } else {\n> unlink(index_name);\n> fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n> }\n\nWhoa. That particular code has been (and is still) correct.\n\nWhen repacking we should pack into a temporary pack and idx file and then\nreplace the real ones after both new pack and its idx are successfully\nwritten, and I thought that is how we've been doing this all the time.\nMaybe the caller has been broken at some point? Sigh...\n"},{"id":"103776","messageId":"200902082108.54048.robin.rosenberg.lists@dewire.com","threadId":"17652","inReplyTo":"7vhc34y9za.fsf@gitster.siamese.dyndns.org","subject":"Re: gc considered dangerous","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T20:08:53Z","receivedAt":"2009-02-08T20:08:53Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 februari 2009 21:00:57 skrev Junio C Hamano:\n> Johannes Schindelin writes:\n> \n> > My preliminary guess is that this code in pack-write.c needs to use the \n> > lock file paradigm:\n> >\n> > if (!index_name) {\n> > \t\t[...]\n> > } else {\n> > unlink(index_name);\n> > fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n> > }\n> \n> Whoa. That particular code has been (and is still) correct.\n> \n> When repacking we should pack into a temporary pack and idx file and then\n> replace the real ones after both new pack and its idx are successfully\n> written, and I thought that is how we've been doing this all the time.\n> Maybe the caller has been broken at some point? Sigh...\n\nI intend to test something like this:\n"},{"id":"103777","messageId":"7vab8wy9le.fsf@gitster.siamese.dyndns.org","threadId":"17652","inReplyTo":"200902080347.25970.robin.rosenberg.lists@dewire.com","subject":"Re: gc considered dangerous","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-08T20:09:17Z","receivedAt":"2009-02-08T20:09:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg writes:\n\n> I've seen this. Running git gc on Windows, while having Elipse open can kill your\n> object database. \n>\n> Eclipse keeps the pack files open most of the time. Then you \n> launch git gui which recommends the user to do a git gc. I never\n> do (it *always* wants to do this), so I haven't encountered the \n> issue, but if gc doesn't find a new optimal pack it tries to rewrite a \n> new pack with the same id. So it rm's the idx file (fine) and the the\n> pack file (not ok) and gives up, which means it has a .pack file with \n> no index, so it cannot use it. Trying git gc again after eclipse exits \n> will execute the final stab on your objects. \n>\n> The underlying bug is ofcource that Windows locks files when\n> they are open. A *nix* user does not suffer from this problem.\n>\n> I'll investigate more at some other time. This is a preliminary\n> analysis.\n\nThat sounds like you are hitting this codepath in git-repack.sh:\n\n\tfullbases=\"$fullbases pack-$name\"\n\tchmod a-w \"$PACKTMP-$name.pack\"\n\tchmod a-w \"$PACKTMP-$name.idx\"\n\tmkdir -p \"$PACKDIR\" || exit\n\n\tfor sfx in pack idx\n\tdo\n\t\tif test -f \"$PACKDIR/pack-$name.$sfx\"\n\t\tthen\n\t\t\tmv -f \"$PACKDIR/pack-$name.$sfx\" \\\n\t\t\t\t\"$PACKDIR/old-pack-$name.$sfx\"\n\t\tfi\n\tdone &&\n\tmv -f \"$PACKTMP-$name.pack\" \"$PACKDIR/pack-$name.pack\" &&\n\tmv -f \"$PACKTMP-$name.idx\" \"$PACKDIR/pack-$name.idx\" &&\n\ttest -f \"$PACKDIR/pack-$name.pack\" &&\n\ttest -f \"$PACKDIR/pack-$name.idx\" || {\n\t\techo >&2 \"Couldn't replace the existing pack with updated one.\"\n\t\techo >&2 \"The original set of packs have been saved as\"\n\t\techo >&2 \"old-pack-$name.{pack,idx} in $PACKDIR.\"\n\t\texit 1\n\t}\n\trm -f \"$PACKDIR/old-pack-$name.pack\" \"$PACKDIR/old-pack-$name.idx\"\n\nWe created a pack and an idx successfully in a pair of temporary files, we\nnotice that pack-$name.idx and/or pack-$name.pack exists and try to move\nthem out of the way, then we install the new ones in their final\ndestination, and we try to see if that move succeeded. If any one of\nthese steps fails, the entire process fails, but along the way we\nshouldn't have lost anything.\n\nI see if .pack can be renamed but .idx can't, then it is possible to get\ninto a state where you have to mix and match pack-$name.pack and\nold-pack-$name.idx.\n"},{"id":"103778","messageId":"200902082110.44151.robin.rosenberg.lists@dewire.com","threadId":"17652","inReplyTo":"7vhc34y9za.fsf@gitster.siamese.dyndns.org","subject":"Re: gc considered dangerous","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T20:10:43Z","receivedAt":"2009-02-08T20:10:43Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 februari 2009 21:00:57 skrev Junio C Hamano:\n> Johannes Schindelin writes:\n> \n> > My preliminary guess is that this code in pack-write.c needs to use the \n> > lock file paradigm:\n> >\n> > if (!index_name) {\n> > \t\t[...]\n> > } else {\n> > unlink(index_name);\n> > fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n> > }\n> \n> Whoa. That particular code has been (and is still) correct.\n> \n> When repacking we should pack into a temporary pack and idx file and then\n> replace the real ones after both new pack and its idx are successfully\n> written, and I thought that is how we've been doing this all the time.\n> Maybe the caller has been broken at some point? Sigh...\n> \nI intend to test something like this (as of yet completely untested)\n\n-- robin\n\ncommit 25a77c80efeb221d165db0bef66b4498aacfac96\nAuthor: Robin Rosenberg \nDate: Sun Feb 8 20:59:30 2009 +0100\n\n Make repack more fail-safe\n \n If renaming an old pack fails try to restore halfway renames\n befor failing. The basis is the assumption that this occurs\n because a files is locked for reading on Windows.\n\ndiff --git a/git-repack.sh b/git-repack.sh\nindex 458a497..e816997 100755\n--- a/git-repack.sh\n+++ b/git-repack.sh\n@@ -94,14 +94,25 @@ for name in $names ; do\n \tchmod a-w \"$PACKTMP-$name.idx\"\n \tmkdir -p \"$PACKDIR\" || exit\n \n-\tfor sfx in pack idx\n-\tdo\n-\t\tif test -f \"$PACKDIR/pack-$name.$sfx\"\n-\t\tthen\n-\t\t\tmv -f \"$PACKDIR/pack-$name.$sfx\" \\\n-\t\t\t\t\"$PACKDIR/old-pack-$name.$sfx\"\n-\t\tfi\n-\tdone &&\n+\tif test -f \"$PACKDIR/pack-$name.pack\"\n+\tthen\n+\t\tmv -f \"$PACKDIR/pack-$name.pack\" \\\n+\t\t\t\"$PACKDIR/old-pack-$name.pack\"\n+\tfi &&\n+\tif test -f \"$PACKDIR/pack-$name.idx\"\n+\tthen\n+\t\tmv -f \"$PACKDIR/pack-$name.idx\" \\\n+\t\t\t\"$PACKDIR/old-pack-$name.idx\" ||\n+\t\t(\n+\t\t\tmv -f $PACKDIR/old-pack-$name.pack\" \\\n+\t\t\t\"$PACKDIR/pack-$name.pack\" || (\n+\t\t\techo >&2 \"Failed to restore after a failure to rename pack-$name to old-$pack\"\n+\t\t\techo >&2 \"Please aquire advice on how to recover from this\"\n+\t\t\techo >&2 \"situation before you proceed.\"\n+\t\t\tfalse\n+\t\t\t)\n+\t\t)\n+\tfi &&\n \tmv -f \"$PACKTMP-$name.pack\" \"$PACKDIR/pack-$name.pack\" &&\n \tmv -f \"$PACKTMP-$name.idx\" \"$PACKDIR/pack-$name.idx\" &&\n \ttest -f \"$PACKDIR/pack-$name.pack\" &&\n@@ -109,6 +120,8 @@ for name in $names ; do\n \t\techo >&2 \"Couldn't replace the existing pack with updated one.\"\n \t\techo >&2 \"The original set of packs have been saved as\"\n \t\techo >&2 \"old-pack-$name.{pack,idx} in $PACKDIR.\"\n+\t\techo >&2 \"Please aquire advice on how to recover from this situation\"\n+\t\techo >&2 \"before you proceed.\"\n \t\texit 1\n \t}\n \trm -f \"$PACKDIR/old-pack-$name.pack\" \"$PACKDIR/old-pack-$name.idx\"\n"},{"id":"103817","messageId":"20090209065919.GB13257@glandium.org","threadId":"17652","inReplyTo":"7vhc34y9za.fsf@gitster.siamese.dyndns.org","subject":"Re: gc considered dangerous","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-02-09T06:59:19Z","receivedAt":"2009-02-09T06:59:19Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sun, Feb 08, 2009 at 12:00:57PM -0800, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > My preliminary guess is that this code in pack-write.c needs to use the \n> > lock file paradigm:\n> >\n> > if (!index_name) {\n> > \t\t[...]\n> > } else {\n> > unlink(index_name);\n> > fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n> > }\n> \n> Whoa. That particular code has been (and is still) correct.\n\nDon't both unlink and open fail in the case the index file is locked in\nWindows ?\n\nMike\n"},{"id":"103818","messageId":"7vskmoukcb.fsf@gitster.siamese.dyndns.org","threadId":"17652","inReplyTo":"20090209065919.GB13257@glandium.org","subject":"Re: gc considered dangerous","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-09T07:43:00Z","receivedAt":"2009-02-09T07:43:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> On Sun, Feb 08, 2009 at 12:00:57PM -0800, Junio C Hamano wrote:\n>> Johannes Schindelin writes:\n>> \n>> > My preliminary guess is that this code in pack-write.c needs to use the \n>> > lock file paradigm:\n>> >\n>> > if (!index_name) {\n>> > \t\t[...]\n>> > } else {\n>> > unlink(index_name);\n>> > fd = open(index_name, O_CREAT|O_EXCL|O_WRONLY, 0600);\n>> > }\n>> \n>> Whoa. That particular code has been (and is still) correct.\n>\n> Don't both unlink and open fail in the case the index file is locked in\n> Windows ?\n\nRead the rest of the thread and read the code.\n\nThe index_file in question is not the file git-repack is telling\npack-write.c to unlink and open.\n"}]}