rcj@burl.UUCP (R. Curtis Jackson) (05/11/84)
USG 5.0 on Vax 11/780; I have a microassembler under development which is compiled with -n (shared text). When I do a 'make install', if the text file is busy at the time when it wants to 'rm' the current version and install the new one, I get this message and the makefile bombs: *** ERROR 8853575 ( I think that number is correct; it doesn't really matter ). Is there an easy way, without piping a 'ps -e' through 'grep' in a while loop, to make sure that my makefile waits until the text file is no longer busy before attempting to 'rm' the current executable? Thanks much in advance, -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd we13 ]!burl!rcj ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj
marcus@pyuxt.UUCP (M. G. Hand) (05/11/84)
The method i have used (successfully) in the past tackles the problem in another way. Firstly you arrange your source and binary so that you execute an *installed* version: that leaves you free to remake the binary in the source directory. Then, when it comes to installing the program you use a make line which effectively does this series of operations: rm -f $(INSD)/n$(PRODUCT) cp $(PRODUCT) $(INSD)/n$(PRODUCT) cd $(INSD); mv $(PRODUCT) o$(PRODUCT); mv n$(PRODUCT) $(PRODUCT); \ rm -f o$(PRODUCT) I say "effectively" because i would use a command macro called, eg $(INSCMD) to hide the dirty work. This results in users gradually swapping over to the new version as they re-invoke the command. Marcus G Hand (pyuxt!marcus)
guy@rlgvax.UUCP (05/12/84)
> The method i have used (successfully) in the past tackles the problem in > another way. ... Then, when it comes to installing the program you use a > make line which effectively does this series of operations: > rm -f $(INSD)/n$(PRODUCT) > cp $(PRODUCT) $(INSD)/n$(PRODUCT) > cd $(INSD); mv $(PRODUCT) o$(PRODUCT); mv n$(PRODUCT) $(PRODUCT); \ > rm -f o$(PRODUCT) The standard USG UNIX "install" command (in "/etc/install") has a "-o" option which does exactly this. The "install" command copies something to an install directory; if the "-o" option is specified, the current copy is renamed OLDwhatever and the new one moved there. By the way, though, the prohibition against removing active shared text program is not a requirement; 4.1BSD removed it by #ifdefing the four lines of code in "sys4.c" out that enforce it (the lines are in the "unlink" routine and read if (ip->i_flag&ITEXT && ip->i_nlink == 1) { u.u_error = ETXTBSY; goto out; } There's no harm in doing so - the inode will not be freed until the last program using the shared text stops using it; the same is true of open files (the inode is not freed until the last program using it closes the file), which the system does let you unlink. A claim I heard was that the only reason that prohibition was there was because if the system crashed, and such files had been unlinked, they would show up as unreferenced inodes in an "fsck". Well, 1) so would any files which were open and had been unlinked, 2) a reasonable version of "fsck" will be able to fix such things automatically at boot time (Berkeley deserves much praise for "fsck -p", which USG did *their own version* of and didn't do it as well! While I'm on that subject, "/etc/fstab" is also very nice - are you listening, USG?), and 3) anybody who's worked with Files-11 (the RSX/IAS/VMS file system) has certainly heard of files "marked for deletion" - the same sort of thing (half-deleted files) appears in lots of other OSes too. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
ggr@hudson.UUCP (Guy Riddle) (05/18/84)
The procedure I usually follow, when installing software where the text file is likely to be in use is: mv /usr/lbin/vnews /usr/tmp/$$ cp vnews /usr/lbin chown netnews /usr/lbin/vnews ... etc. So if the text files happen to be in use, they will sit in /usr/tmp until the next reboot discards them. === Guy Riddle == AT&T Bell Laboratories, New Jersey ===
dave@elecvax.SUN (Dave Horsfall) (05/22/84)
Instead of trying to remove the current object, why not simply rename it instead? Our 'install' command procedure renames things from say /bin/fred to /bin/fred$$old (if told to do so with a - flag) where '$$' is of course the shell pid. It also chmod 0 and chown root it as well, and such things show up on a nightly inspection of the file system. Dave Horsfall Computing Services Unit University of NSW Australia path: ...decvax!mulga!dave:csu60