home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / sun / misc / 4225 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.1 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.sys.sun.misc
  4. Subject: Re: tmp doesn't seem to be clearing. . .
  5. Keywords: tmp files hvtmp
  6. Message-ID: <14636@auspex-gw.auspex.com>
  7. Date: 15 Sep 92 05:24:40 GMT
  8. References: <1992Sep10.120029.6372@eng.ufl.edu> <1992Sep15.042444.3062@midway.uchicago.edu>
  9. Sender: news@auspex-gw.auspex.com
  10. Organization: Auspex Systems, Santa Clara
  11. Lines: 31
  12. Nntp-Posting-Host: bootme.auspex.com
  13.  
  14. > We just installed 4.1.2 on a few machines, and after noticing a large
  15. > amount of .getwd files in /tmp, found that the sticky bit is turned on
  16. > by default for the /tmp directory.  We turned it off. 
  17.  
  18. Track down any binaries you have at your site that were compiled under
  19. SunOS 4.0[.x], and statically linked with "-lc" (which probably means
  20. completely statically linked), and get their owners to recompile them,
  21. if they're owned by somebody at your site (as opposed to being, say,
  22. some third-party package).
  23.  
  24. ".getwd" was, as I remember, a cache of "dev_t"/mount-point pairs
  25. maintained by the SunOS 4.0[.x] version of the "getwd()" routine.  The
  26. SunOS 4.1[.x] "getwd()" routine doesn't maintain that cache; the "mount"
  27. command maintains it in "/etc/mtab".
  28.  
  29. Binaries compiled under 4.0[.x], and dynamically linked with "-lc", will
  30. automatically pick up the 4.1[.x] version of "getwd()" when run, and
  31. won't create ".getwd" files in "/tmp" (and won't get tripped by other
  32. problems in the 4.0[.x] version of "getwd()"; as I remember, the 4.0[.x]
  33. version tended to "stat" lots of things in "/", and if one of them was
  34. mounted from an NFS server that was down, you lost).
  35.  
  36. Binaries compiled under 4.0[.x], and *statically* linked with "-lc",
  37. have the old version of "getwd()" bound into their executable image, and
  38. don't automatically pick up the 4.1[.x] version when run under 4.1[.x].
  39.  
  40. (They won't pick up new versions of routines when run under 5.x, either;
  41. they'll probably blow up completely when run under 5.x.)
  42.  
  43. If you're getting ".getwd" files in "/tmp" on a 4.1[.x] system, old
  44. statically-linked programs such as that are to blame....
  45.