NetBSD Problem Report #33753

From dholland@eecs.harvard.edu  Sat Jun 17 03:17:53 2006
Return-Path: <dholland@eecs.harvard.edu>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 4A9D763B882
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 17 Jun 2006 03:17:53 +0000 (UTC)
Message-Id: <20060617011554.C390FF7A4@tanaqui.eecs.harvard.edu>
Date: Fri, 16 Jun 2006 21:15:54 -0400 (EDT)
From: dholland@eecs.harvard.edu
Reply-To: dholland@eecs.harvard.edu
To: gnats-bugs@NetBSD.org
Subject: don't installworld to a full disk
X-Send-Pr-Version: 3.95

>Number:         33753
>Category:       misc
>Synopsis:       don't installworld to a full disk
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    lukem
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 17 03:20:01 +0000 2006
>Closed-Date:    Mon Jun 05 05:28:42 +0000 2023
>Last-Modified:  Mon Jun 05 05:28:42 +0000 2023
>Originator:     David A. Holland <dholland@eecs.harvard.edu>
>Release:        NetBSD 3.99.21 (-20060616)
>Organization:
>Environment:
System: NetBSD tanaqui 3.99.21 NetBSD 3.99.21 (TANAQUI) #4: Fri Jun 16 11:23:47 EDT 2006 dholland@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386
Architecture: i386
Machine: i386
>Description:

	I discovered the hard way today that if you installworld to a
	full (or nearly full) disk, it turns into "eraseworld" - it
	truncates what it touches and it doesn't stop, so if running
	unattended it'll trash the system pretty thoroughly.

	Recovery is pretty straightforward: clear some space, then
	redo the installworld. (But if using build.sh, be sure it
	doesn't try to rebuild nbmake, as that will fail in bizarre
	ways.)

	It would be nice if it didn't do this. Not a tremendously big
	problem though.

>How-To-Repeat:

	As above.

>Fix:
	Probably not that hard. :-)

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: misc-bug-people->lukem
Responsible-Changed-By: lukem@NetBSD.org
Responsible-Changed-When: Wed, 24 May 2023 11:09:23 +0000
Responsible-Changed-Why:


State-Changed-From-To: open->feedback
State-Changed-By: lukem@NetBSD.org
State-Changed-When: Wed, 24 May 2023 11:09:23 +0000
State-Changed-Why:

If the fix is "Probably not that hard. :-)", do you have
any further details on what that fix is?

Is the issue that install(1) doesn't exit non-zero if it can't
install the file (via temp file first, then atomic rename) ?

Or is the issue that the makefiles don't correctly handle
non-zero exits from install(1) ?

Or is it something else?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 28 May 2023 05:45:42 +0000
State-Changed-Why:
I don't remember what I was thinking in 2006, and any diagnosis I did
then would have ended up in here (thus, little or none) so IDK. But
remember that installworld runs by creating and unpacking sets, not
install(1), so the problem is probably somewhere in the tar/pax/whatnot
borg. Or was. And probably the problem was total failure to detect
write errors at all.

Whether this is still current I have no idea; it should be possible to
test it with a scratch partition.


From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/33753 (don't installworld to a full disk)
Date: Sun, 28 May 2023 06:59:35 -0000 (UTC)

 dholland@NetBSD.org writes:

 >Synopsis: don't installworld to a full disk

 >State-Changed-From-To: feedback->open
 >State-Changed-By: dholland@NetBSD.org
 >State-Changed-When: Sun, 28 May 2023 05:45:42 +0000
 >State-Changed-Why:
 >I don't remember what I was thinking in 2006, and any diagnosis I did
 >then would have ended up in here (thus, little or none) so IDK. But
 >remember that installworld runs by creating and unpacking sets, not
 >install(1), so the problem is probably somewhere in the tar/pax/whatnot
 >borg. Or was. And probably the problem was total failure to detect
 >write errors at all.

 >Whether this is still current I have no idea; it should be possible to
 >test it with a scratch partition.

 From the copy function of pax:

                 if ((fddest = file_creat(arcn, 0)) < 0) {
                         rdfile_close(arcn, &fdsrc);
                         purg_lnk(arcn);
                         continue;
                 }

                 cp_file(arcn, fdsrc, fddest);
                 file_close(arcn, fddest);


 file_creat creates a temporary file.
 cp_file copies the data.
 file_close closes the destination and renames it.

 However, any kind of error during the copy or close (like disk full)
 just produces a warning, it doesn't prevent the operation from being
 aborted or the old file from being kept.

State-Changed-From-To: open->analyzed
State-Changed-By: lukem@NetBSD.org
State-Changed-When: Sun, 28 May 2023 20:21:24 +0000
State-Changed-Why:
Michael van Elst has analyzed the issue.


From: "Luke Mewburn" <lukem@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/33753 CVS commit: src/bin/pax
Date: Sun, 28 May 2023 21:42:40 +0000

 Module Name:	src
 Committed By:	lukem
 Date:		Sun May 28 21:42:40 UTC 2023

 Modified Files:
 	src/bin/pax: ar_subs.c buf_subs.c extern.h file_subs.c

 Log Message:
 pax: don't overwrite destination if -r -w copy fails

 Add more error handling to pax -r -w so that any failure
 during the copy to the temporary file (including a failed flush)
 prevents any existing destination file from being replaced
 with the partial (including possibly empty) temporary file.
 The partial temporary file is removed.  pax still exists non-zero.

 Thanks to Michael van Elst (mlelstv@) for the analysis
 of the problem in the PR.

 Should fix PR misc/33753.


 To generate a diff of this commit:
 cvs rdiff -u -r1.57 -r1.58 src/bin/pax/ar_subs.c
 cvs rdiff -u -r1.30 -r1.31 src/bin/pax/buf_subs.c
 cvs rdiff -u -r1.60 -r1.61 src/bin/pax/extern.h
 cvs rdiff -u -r1.64 -r1.65 src/bin/pax/file_subs.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: analyzed->feedback
State-Changed-By: lukem@NetBSD.org
State-Changed-When: Sun, 28 May 2023 21:46:18 +0000
State-Changed-Why:

I've enhanced the error handling in pax (see the commit message
attached to the PR), which should resolve this specific problem.

Please review / confirm. Thanks


State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 05 Jun 2023 05:28:42 +0000
State-Changed-Why:
LGTM


>Unformatted:

Home	PR Database Search