ETXTBSY

[Bob Stockler]

Ken Brody wrote (on Wed, Oct 26, 2005 at 09:14:52PM -0400):

| Quoting Jean-Pierre A. Radley (Wed, 26 Oct 2005 19:21:23 -0400):
| 
| > From a SCO engineer:
| [... the new VM architecture in SCO 6 ...]
| > | However, like all diamonds, it has flaws.  ETXTBSY is no longer
| > | supported.  This is pretty much a result of one of the key aspects
| > | of the VM design, which is that there is only one copy of a given
| > | file page in the system for all uses.  Thus, any attempt to put back
| > | ETXTBSY is going to be so expensive that it's not going to be worth
| > | it unless there is some huge revenue opportunity that is going to be
| > | lost simply because ETXTBSY is not supported.  This seems an unlikely
| > | scenario.
| [...]
| 
| First, let me admit that I have no access to SCO source, and this is
| all speculation, based on my somewhat limited experience with Unix
| kernel internals.
| 
| 
| Now, can we assume that each running process has a struct which
| contains, among other things, a pointer to an open inode struct?
| (It would need this inode pointer in order to keep track of where
| to load pages from disk to memory.)
| 
| Next, can we assume that each open inode struct does/can contain a
| member containing the number of times this inode is open for an
| active process?  (Note the "can contain" possibility.  Since it is
| the kernel which starts processes, and sets up the proc struct, it
| knows that the inode is open for execution.)
| 
| Finally, can we assume that each open instance of this inode at the
| file I/O level contain a pointer to a single open inode struct for
| this file?  (This is needed to know which inode is open, and to make
| sure that all open instances share the inode information, such as
| filesize and status, while the individual file structs contain
| information such as file offset and access modes.)
| 
| Given the above perfectly reasonable assumptions (and I believe that
| they are all true, based on what I remember while learing about Unix
| kernel internals years ago), why isn't it possible to simply have the
| kernel's file open code check the inode's "number of processes having
| this inode open for execution" value, and if not zero, fail any open
| requests for writing with an error code of ETXTBSY?
| 
| Is there something about the VM architecture that precludes a proc
| entry from pointing to the inode struct?

This is all WAY above my head, but I just did a Google for
ETXTBSY and found it to be a much discussed topic on all
sorts of flavors of UNIX and UNIX-like OS's.

Maybe POSIX needs to address this (and do something like
insisting no -n flag to echo as they've done).

Bob

-- 
Bob Stockler  +-+  bob at trebor.iglou.com  +-+  http://members.iglou.com/trebor
Author: MENU EDIT II - The BEST Creator/Editor/Manager for filePro User Menus.
Fully functional (time-limited) demos available by email request (specify OS).