Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: SunOS 4.0.3 SCSI tape close error: EPERM
Keywords: Sun 4.0.3 SCSI tape oh-my grmphh close(2)
Message-ID: <2337@auspex.auspex.com>
Date: 5 Aug 89 18:04:13 GMT
References: <419@sunny.ucdavis.edu> <212@estinc.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 75

>>Has anyone running SunOS 4.0.3 observed that closing a 1/4"
>>SCSI tape after read/write returns EPERM?  This happens on
>>a 3/150 with /dev/rst[08].  It may have happened under
>>4.0.1 too, but I don't specifically remember.
>
>Yes, I noticed and reported this bug last November, when I first tried
>some code on a Sun-4 under 4.0.1 that bothered to check the status of
>the close() call.  Looks like it's still there...

Oh, this one again.  The problem is due to the way special files are
handled in SunOS (and other systems that have picked up recent versions
of the VFS mechanism).  The problem is that, as long as the device is
open, the vnode for the device on the underlying file system is
"shadowed" by a vnode for the "specfs" file system.  Updates to the
accessed and modified times go to that "shadow" vnode and not the native
vnode.  When the device is closed, the "specfs" code uses a VOP_SETATTR
to push the times back to the native vnode; unfortunately, UNIX tends to
require that you either be the super-user or the owner of a file in
order to set the accessed or modified times of a file.

"specfs" could try to forge sufficiently-powerful credentials when it
performs the VOP_SETATTR operation; it doesn't, however.  I think the
fix for this is straightforward; it may appear in a future SunOS
release, and possibly in a future NFS source release as well.  (I
certainly hope it at least gets into S5R4, unless the fix *isn't*
straightforward....)

>On an unrelated note, has anyone else noticed that the system does
>not prevent you from overwriting an executable that is currently
>executing?  For example, make a copy of tar in /tmp/tar, create a
>tar archive in /tmp/tar.out that contains tar, and then try to
>extract tar over itself.  You usually get a core dump.  On any other
>UNIX I've tried, you get an errno for "text busy".

Yup.  SunOS 4.x doesn't support shared texts; it supports copy-on-write
private mappings.  SunOS 4.x doesn't protect against attempts to write
to files mapped in that fashion; I don't know what the pros and cons of
having attempts to write to files of that sort copy the pages written to
would be.  Basically, the file system "write" code establishes a shared,
writable mapping to the relevant region of the file, and copies data
from user space into the mapped region.  The VM code might be able to
detect that somebody has part or all of the same region mapped
copy-on-write, and cause the other mappings to be remapped to a copy of
the page; however, 1) I don't know if this is possible with the current
VM system, 2) I don't know how difficult it is, or what the performance
impact would be, and 3) I don't know if this change in semantics would
cause other problems.

Given that said extraction operation doesn't work *regardless* of
whether such writes are detected or not, the correct way to extract a
"tar" file that would overwrite "tar" itself is to *move* "tar" off to
"tar.save" or something like that, and use "tar.save" to extract the
file.

(The subtle distinction between "shared texts" and "shared copy-on-write
mappings" lets SunOS permit you to remove the last link to an active
"shared-text" program without violating a rather stupid clause in the
SVID that requires the last unlink of a file whose text is active to
fail with ETXTBSY. 

Somebody claimed that said "feature" was put into V7 to reduce the
probability of an orphaned file from a crash - any file that had been
unlinked while the text was still active would still be around on disk,
but with no links, until the last reference to the text disappeared, so
if the machine crashed before said reference disappeared, you would have
an orphaned file - but 1) the same happens with files that were unlinked
while still open, and you can't forbid *that* without breaking many
programs and 2) "fsck" can fix that problem, anyway. 

Berkeley saw the bogosity in that - said restriction makes it a royal
pain to install new versions of programs that are currently being used,
since you have to leave one link around until the old version is no
longer being used - and removed the restriction.  The S5 folks didn't do
so, alas, and somebody working on the SVID didn't realize that the
restriction was pointless and didn't belong there, so they stuck it in.)