HEDRICK@RUTGERS.ARPA (08/04/84)
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> This message is in response to the question about how to find files that you have changed, and make sure they survive updating to a new releae of Unix. Please forgive me if the following seems obvious. We are a new Unix site, having used only Tops-20 in the past. The following procedure seemed non-obvious but useful to me. Since this list is for new system managers, the same may be true for other readers. We have to face the problem of locating changed files in a more urgent form than most of you. We have a Pyramid, and Pyramid puts out new releases about once every 2 months. (By the way, please don't interpret this as a complaint. I am glad that they distribute updates so often. It means we can usually just wait for the next distribution, rather than having to patch things ourselves based on various bug reports.) If we don't find a good way to localize our changes, we will spend all of our time updating. Typically our distributions come in the following forms: - a complete / - a complete /usr, but one that does not have some of the optional, extra-cost pieces of software - individual tapes for some software that goes on /bin or /usr, and for things like source files, which we put on a separate file system. This tapes are not necessarily synchronized with the new releases of / and /usr. It would be very nice if we could separate out all local changes, so they were in some subdirectory of /usr/local. However this didn't seem totally practical. The problem is that we make local additions to lots of directories, including /usr/lib/emacs/maclib, /usr/man/man..., the kernel sources, /etc, /usr/adm, etc. It is clear that we could put these changes into subdirectories of /usr/local, but we would have to modify man, the makefile used for building a kernel, etc. This seems too much of a pain. Instead, I propose the following. The extra-cost optional products are typically one or two files that go on /bin, and library and/or source files that reside on their own directory or directories. We treat the one or two files as if they were local additions, for purposes of bringing up new versions of / and /usr. Typically we bring the distribution tape onto its own directory hierarchy, and then copy those one or two files onto /bin, etc. Because we use the "cp" command to install them, their modification dates are recent. (You will see the signficance of this in a minute.) If anyone needs to see the real modification date, they can always look at the master copy on the distribution directory. I have found that local files fall into one of two categories. On the one side we have whole directory hierarchies (e.g. /usr/spool) that are purely local or associated with some optional package (e.g. /usr/lib/emacs). We keep a list of these, and simply dump them all onto tape before bringing in a new version of / or /usr. On the other side, we have a few files spread out in directories which are mainly unchanged from the distribution. In order to catch these, we create a file ".update" in the top level directory of any directory hierarchy where we put distributions. The last modification date of this file represents the boundary between files that we left unmodified from the distribution, and those that we modified ourselves. This means that we have a /.update, /usr/.update, etc. Before bringing up a new version, we write a separate tape containing only files modified since the corresponding .update. The -newer option on "find" is useful for this. (A note to developers: it would be nice to be able to ask find to find all files on the root file system. "find / ..." unfortunately finds everything.) Once we have written all of these tapes, we then do the following: 1) bring in the distributed / and /usr 2) cp /dev/null /.update and /usr/.update 3) bring in the tapes containing whole directories 4) bring in the tapes containing files that we have changed, specifying -m to TAR. This causes the current date/time to be used as the modification date. Thus the files will continue to show as modified in future installations. We could handle new distributions of the separate products the same way as / and /usr. We would have .update files at the base of the directory hierarchy where we put them. Indeed we do this in some cases. However for the source directories, I want to keep both our changed source and the original, so I rename the original to foo.c.ORIG. In this case I can just look for *.ORIG to see what has changed. It is not yet clear whether I will need the .update file for these directories. (Of course if I add entirely new modules, I would.) When I have time to learn one of the source control systems, I suspect that I will use that for the source directories instead of the .ORIG kludge. -------