home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!auspex-gw!guy
- From: guy@Auspex.COM (Guy Harris)
- Newsgroups: comp.unix.programmer
- Subject: ETXTBSY on open for write (was Re: Process & Signal Question)
- Message-ID: <14145@auspex-gw.auspex.com>
- Date: 19 Aug 92 04:13:12 GMT
- References: <Bt5tp0.9JI@gumby.ocs.com> <1992Aug18.145412.6352@wuecl.wustl.edu> <1992Aug18.205521.4078@ringer.cs.utsa.edu>
- Sender: news@auspex-gw.auspex.com
- Organization: Auspex Systems, Santa Clara
- Lines: 26
- Nntp-Posting-Host: bootme.auspex.com
-
- >If you are talking about a file which is being shared via NFS, this could
- >happen, because NFS does not completely implement the UNIX file deletion
- >semantics.
-
- Well, that's not the *only* reason it can happen. It can also happen if
- you copy stuff to a file, as well; even if the system running the
- program won't let you open a shared executable for writing if some
- process is running from it, a process on some other system - another
- client of the same server, or the server itself if the process running
- from the file is on a client - could write to the file.
-
- In SunOS 4.x and, I think, SVR4, the system *will* let you open a shared
- executable for writing even if some process on the same machine is
- running from it. It might be possible to implement the more
- "traditional" semantics, but to properly generalize it, it'd have to
- work on shared libraries as well, which'd probably mean that:
-
- 1) the run-time linker would have to use some call other than
- "mmap()" to map in the shared libraries, or would have to use
- some special flag to "mmap()";
-
- 2) the system would have to decide that anybody mapping
- something copy-on-write wants to prevent anybody else from
- opening the file for writing (you don't have to open a file
- for writing to map it writable, as long as you're mapping it
- copy-on-write as well).
-