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:    Wed Aug 07 11:44:14 +0000 2024
>Last-Modified:  Wed Aug 07 11:44:14 +0000 2024
>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


State-Changed-From-To: closed->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Mon, 05 Aug 2024 03:34:53 +0000
State-Changed-Why:
Looks like this could use pullup-9 and pullup-10.


State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Mon, 05 Aug 2024 14:52:24 +0000
State-Changed-Why:
pullup-9 #1863 https://releng.netbsd.org/cgi-bin/req-9.cgi?show=1863
pullup-10 #776 https://releng.netbsd.org/cgi-bin/req-10.cgi?show=776


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/33753 CVS commit: [netbsd-10] src
Date: Wed, 7 Aug 2024 10:52:49 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Aug  7 10:52:49 UTC 2024

 Modified Files:
 	src/bin/pax [netbsd-10]: ar_subs.c buf_subs.c extern.h file_subs.c
 	    ftree.c pax.c
 	src/tests/bin/pax [netbsd-10]: t_pax.sh

 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #776):

 	bin/pax/buf_subs.c: revision 1.31
 	tests/bin/pax/t_pax.sh: revision 1.3
 	tests/bin/pax/t_pax.sh: revision 1.4
 	tests/bin/pax/t_pax.sh: revision 1.5
 	tests/bin/pax/t_pax.sh: revision 1.6
 	tests/bin/pax/t_pax.sh: revision 1.7
 	bin/pax/extern.h: revision 1.61
 	bin/pax/pax.c: revision 1.50
 	bin/pax/pax.c: revision 1.51
 	bin/pax/file_subs.c: revision 1.65
 	bin/pax/ftree.c: revision 1.43
 	bin/pax/ar_subs.c: revision 1.58

 pax: exit 0 if stdin filelist is used and empty

 If copying a list of files from stdin, exit zero instead of non-zero
 if there are no files supplied.

 AFAICT, POSIX doesn't require a non-zero an error in this situation,
 since there are no files to not match.

 Fix from PR bin/41736 by Lloyd Parkes.

 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.

 tests/bin/pax: Add test for pax list in an ungettable cwd.
 The list operation has no need to touch the file system, so it should
 have no need for open(".") or getcwd() to succeed.

 PR bin/44498: tar(1) unnecessarily demands that getcwd() work
 (The PR was filed about tar(1), which is now bsdtar by default, but
 the issue applies to pax(1) too and would continue to apply to tar(1)
 if you set MKBSDTAR=no.)
 pax(1): Don't require open(".") or getcwd to work for list operation.

 PR 44498: tar(1) unnecessarily demands that getcwd() work
 tests/bin/pax: Test pax(1) succeeds with empty file list on stdin.

 PR bin/41736: pax reports an error when copying zero files
 tests/bin/pax: Add some more cwd-related test cases.

 PR bin/44498: tar(1) unnecessarily demands that getcwd() work
 pax(1): Only require getcwd if we're reading without --insecure.

 No other paths use the result of getcwd.

 PR bin/44498: tar(1) unnecessarily demands that getcwd() work


 To generate a diff of this commit:
 cvs rdiff -u -r1.57 -r1.57.2.1 src/bin/pax/ar_subs.c
 cvs rdiff -u -r1.30 -r1.30.2.1 src/bin/pax/buf_subs.c
 cvs rdiff -u -r1.60 -r1.60.6.1 src/bin/pax/extern.h
 cvs rdiff -u -r1.64 -r1.64.10.1 src/bin/pax/file_subs.c
 cvs rdiff -u -r1.42 -r1.42.42.1 src/bin/pax/ftree.c
 cvs rdiff -u -r1.49 -r1.49.10.1 src/bin/pax/pax.c
 cvs rdiff -u -r1.1 -r1.1.44.1 src/tests/bin/pax/t_pax.sh

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

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/33753 CVS commit: [netbsd-9] src
Date: Wed, 7 Aug 2024 10:55:30 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Aug  7 10:55:29 UTC 2024

 Modified Files:
 	src/bin/pax [netbsd-9]: ar_subs.c buf_subs.c extern.h file_subs.c
 	    ftree.c pax.c
 	src/tests/bin/pax [netbsd-9]: t_pax.sh

 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #1863):

 	bin/pax/buf_subs.c: revision 1.31
 	tests/bin/pax/t_pax.sh: revision 1.3
 	tests/bin/pax/t_pax.sh: revision 1.4
 	tests/bin/pax/t_pax.sh: revision 1.5
 	tests/bin/pax/t_pax.sh: revision 1.6
 	tests/bin/pax/t_pax.sh: revision 1.7
 	bin/pax/extern.h: revision 1.61
 	bin/pax/pax.c: revision 1.50
 	bin/pax/pax.c: revision 1.51
 	bin/pax/file_subs.c: revision 1.65
 	bin/pax/ftree.c: revision 1.43
 	bin/pax/ar_subs.c: revision 1.58

 pax: exit 0 if stdin filelist is used and empty

 If copying a list of files from stdin, exit zero instead of non-zero
 if there are no files supplied.

 AFAICT, POSIX doesn't require a non-zero an error in this situation,
 since there are no files to not match.

 Fix from PR bin/41736 by Lloyd Parkes.

 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.

 tests/bin/pax: Add test for pax list in an ungettable cwd.
 The list operation has no need to touch the file system, so it should
 have no need for open(".") or getcwd() to succeed.

 PR bin/44498: tar(1) unnecessarily demands that getcwd() work
 (The PR was filed about tar(1), which is now bsdtar by default, but
 the issue applies to pax(1) too and would continue to apply to tar(1)
 if you set MKBSDTAR=no.)
 pax(1): Don't require open(".") or getcwd to work for list operation.

 PR 44498: tar(1) unnecessarily demands that getcwd() work
 tests/bin/pax: Test pax(1) succeeds with empty file list on stdin.

 PR bin/41736: pax reports an error when copying zero files
 tests/bin/pax: Add some more cwd-related test cases.

 PR bin/44498: tar(1) unnecessarily demands that getcwd() work
 pax(1): Only require getcwd if we're reading without --insecure.

 No other paths use the result of getcwd.

 PR bin/44498: tar(1) unnecessarily demands that getcwd() work


 To generate a diff of this commit:
 cvs rdiff -u -r1.56 -r1.56.46.1 src/bin/pax/ar_subs.c
 cvs rdiff -u -r1.29 -r1.29.4.1 src/bin/pax/buf_subs.c
 cvs rdiff -u -r1.59.36.1 -r1.59.36.2 src/bin/pax/extern.h
 cvs rdiff -u -r1.64 -r1.64.2.1 src/bin/pax/file_subs.c
 cvs rdiff -u -r1.42 -r1.42.34.1 src/bin/pax/ftree.c
 cvs rdiff -u -r1.49 -r1.49.2.1 src/bin/pax/pax.c
 cvs rdiff -u -r1.1 -r1.1.36.1 src/tests/bin/pax/t_pax.sh

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

State-Changed-From-To: pending-pullups->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 07 Aug 2024 11:44:14 +0000
State-Changed-Why:
fixed in HEAD, pulled up to 9 and 10


>Unformatted:

Home	PR Database Search