PR/59957 CVS commit: src/sbin

["Robert Elz" <kre%netbsd.org@localhost>]

The following reply was made to PR bin/59957; it has been noted by GNATS.

From: "Robert Elz" <kre%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/59957 CVS commit: src/sbin
Date: Sun, 3 May 2026 17:49:58 +0000

 Module Name:	src
 Committed By:	kre
 Date:		Sun May  3 17:49:58 UTC 2026
 
 Modified Files:
 	src/sbin/fsck: openspecial.c partutil.h
 	src/sbin/newfs: newfs.c
 	src/sbin/newfs_ext2fs: newfs_ext2fs.c
 	src/sbin/newfs_msdos: newfs_msdos.c
 	src/sbin/tunefs: tunefs.c
 
 Log Message:
 Undo some of the previous, restore flexibility
 
 This is related to PR bin/59957 (in that it is a continuation/
 alteration of the previous fix).   This was primarily designed
 to (hopefully) fix the ~80 extra ATF test failures that the previous
 solution caused, by allowing the utilities to work as they had
 previously, rather than attempting to enforce one universal true
 world order.
 
 Change the openspecial() function to be findspecial() as it no longer
 opens anything - but leave it in openspecial.c for several reasons:
 
 First, it might make sense to recreate openspecial() for use in just
 those utilities that want to do all that it did (just 2 of the four
 that were modified to use it).
 
 Also, this function (or functions) really should be moved to libutil,
 rather than buried in sbin/fsck (which doesn't even use it/them at all
 - though could perhaps use the findspecial() variant), and I didn't see
 the point in deleting one file, creating another, only to delete that
 new one in a few days.
 
 And third, renaming it would have meant futzing with Makefiles which
 I personally prefer not to get involved in whenever possible - and which
 would also need to be done differently if the function(s) move to libutil.
 
 The issues:
 
 newfs_msdos wants to be able to create new files (at a point beyond where
 the code was changed) so forcing an err() exit when the open of the
 non-existing file failed broke things (that's the cause of perhaps all
 of the test failures - certainly most).
 
 tunefs has no need to enforce use of something other than a block device -
 in fact, it is often better to use the block device (makes no difference
 to efficiency, only the superblock is touched) and using the block device
 provides a little extra protection against attempting to modify a mounted
 filesystem (which would "work", but be undone the next time the in-core
 superblock is flushed, leading to "what happened there, I know I checked
 it had worked??" kinds of issues).
 
 newfs and newfs_ext2fs could have continued using the openspecial()
 function (and might get returned to that way again) if that function
 gets recreated.
 
 [ok:christos]
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.1 -r1.2 src/sbin/fsck/openspecial.c
 cvs rdiff -u -r1.4 -r1.5 src/sbin/fsck/partutil.h
 cvs rdiff -u -r1.121 -r1.122 src/sbin/newfs/newfs.c
 cvs rdiff -u -r1.12 -r1.13 src/sbin/newfs_ext2fs/newfs_ext2fs.c
 cvs rdiff -u -r1.46 -r1.47 src/sbin/newfs_msdos/newfs_msdos.c
 cvs rdiff -u -r1.59 -r1.60 src/sbin/tunefs/tunefs.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.