OT: SCO 6.0 - MAJOR BUG!!!!!

[Kenneth Brody]

Quoting Fairlight (Mon, 24 Oct 2005 13:39:18 -0400):
[...]
> > What happens if someone is running testcicq and then you do:
> >
> >     echo hello >testcicq
>
> Apparently, testing with a copy of the same binary is a Bad Idea.  It
> works fine.  Doing what you suggest, or copying a different version onto
> the one being run results in a bus error, although no core dump.
[...]
> What made you suspect that using the same binary was what made it work,
> out of curiosity.  It might use the same starting inode, but the blocks
> could potentially all be different, couldn't they?  That's why I didn't
> actually think it made a difference so long as you used cp to replace it.

I doubt that it keeps a list of blocks occupied by the binary, when it
could simply keep the inode open.  By copying the same file back into
place, you've pulled the rug out from under the proc, but you've replaced
it with an identical rug.  Everything is still exactly in the same place
it was before, at least at the file I/O level.

> Okay, I decided to take this testing further, based on the above
> thinking.
>
> With centericq-4.20.0 running, I did:
>
> [FLAdmin] [~/storage/bin] [1:09pm]: rm centericq-4.20.0
> [FLAdmin] [~/storage/bin] [1:12pm]: echo "hello" > centericq-4.20.0
> [FLAdmin] [~/storage/bin] [1:13pm]: cp centericq-4.12.0 centericq-4.20.0
>
> No bus errors, and the program chugs on.  An unlink first lets it keep
> going without issue.  Does that work on SCO?

Since the inode is still open (at least it should be), the new copy of
the "program" should have a new inode number, and therefore have no
effect on running processes.

> So the difference is that if you unlink it, it does what?  Drags the
> -entire- thing to memory or swap so that it can keep running, but if
> you overwrite the file at the same inode without an unlink then it gets
> corrupted memory?

No.  Unlinking an open file keeps the inode as-is (with zero links to it)
until the final open handle on it is closed, at which time the inode and
its resources are freed.

> Okay, I might buy that.  But since that works, I looked at 'man cp':
>
>      -f    Unlink.  If a file descriptor for a  destination  file
>            cannot  be obtained, attempt to unlink the destination
>            and proceed.
>
> So, I tried (with a 4.12.0 version of cicq in the centericq-4.20.0
> position):
>
> cp -f testcicq centericq-4.20.0
>
> Supposedly this should act the same as unlinking first, but it caused a
> bus error, same as without -f.  This leads me to believe that the vague
> "If a file descriptor for a destination file cannot be obtained" clause
> (they don't say -where- the fd should be found, is what I find vague)
> must be kicking into effect, and no unlink was performed.

Basically, it means "does open(filename,O_WRITE) succeed"?  Since cp was
able to open the file for writing, the "-f" is a no-op here.

[...]

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com