:On Fri, Apr 14, 2006 at 12:39:29AM -0700, Matthew Dillon wrote:
:> What I think is happening is that /dev/null gets created 644, then
:> chmod'd 666, but the chmod doesn't get synchronized to disk in a timely
:> manner. A normal shutdown ought to sync it, but an abnormal shutdown
:> might not.
:
:mknod(2) does accept the mode for the created node, but there's no way to
:tell mknod(8) to set the mode on the command line arguments (except via
:umask setting). The mode argument to mknod(2) is set to 0666 and is
:overridden by umask setting(usually set to 022). I think that the following
:small patch to MAKEDEV is enough to avoid the glitch. (Making mknod(8) to
:accept `-m mode' looks cleaner, but relying on the new option doesn't work
:when DESTDIR is set to other location than /).
:
:Index: etc/MAKEDEV
:===================================================================
:RCS file: /home/source/dragonfly/cvs/src/etc/MAKEDEV,v
:retrieving revision 1.20
:diff -u -r1.20 MAKEDEV
:--- etc/MAKEDEV 7 May 2005 17:38:33 -0000 1.20
:+++ etc/MAKEDEV 14 Apr 2006 08:41:31 -0000
:@@ -374,8 +374,11 @@
: # Finally, set ownership and permissions.
: #---------------------------------------------------------------------
:
:+ umask=`echo $perms | $tr '01234567' '76543210'`
:+ savedumask=`umask`
:+ umask $umask
: $mknod $dev$unit $1 $2 $3 $owner
:- chmod $perms $dev$unit
:+ umask $savedumask
: }
I'd rather fix the issue of the kernel not synchronizing the inode
in a timely fashion. If we adjust MAKEDEV first then we'll stop getting
bug reports about /dev/null and not know that it has been fixed for
good :-)
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
