Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!kenj
From: kenj@yarra.oz.au (Ken McDonell)
Newsgroups: comp.sys.pyramid
Subject: Re: Root File System Invisible File(s)
Message-ID: <70904@yarra.oz.au>
Date: 3 May 91 21:58:48 GMT
References: <521@wrdis01.af.mil>
Organization: Pyramid Technology Corp PL, Melb., Australia
Lines: 75

I don't have an explanation, but some information that may help and a couple
of additional questions.

kerr@wrdis01.af.mil (Kerr) writes:

>I run a Pyramid MIServer 4/2 and have had a problem recently with the root 
>file system filling up (hold on don't answer just yet) with no visible file 
>that has has the amount of space that is missing.
>At times there will be 5 megabytes free and it will vanish with no apparent
>cause. The free space reappears with the same mystery.

>I have looked at every file (visible to find/ls/du) in the root file system 
>that has changed during the period of the when the space disappears and none of 
>the files can account for the loss/gain of space.  

>Yesterday the local FE was here and watched as the only files changing
>were the /etc/.*tmp files (they were getting bigger) and poof there was
>1 megabyte more of FREE space than minutes earlier.

>Are there programs that create files with no directory entrys that can
>change size at will? If there are such invisible files how does one find out 
>what program is creating them?

The answer to the first question is "yes", the second is "with great
difficulty".

There are 2 ways in which blocks in the file system can be allocated to
files that are not accessible through the directory naming structure
(and hence cannot be found using find, du, ls -Ra, ...)

1. mounting a file system on a non-empty directory

    + create a 1 Mbyte file in /mnt (blocks allocated in the root file system)
    + mount /dev/iop/pdisk... /mnt
    + you cannot find the file in /mnt any more, but the space is still
      allocated

   Technically this would be aenough to recreate your scenario, but
   this would require file systems to be dynamically mounted and
   unmounted, and the equivalent of fiddling with files in /mnt when
   the file system is unmounted -- seems a little far fetched?

2. unlinking an open file

    + f = creat("/trickyfile", 0644);	/* call me old-fashioned! */
      unlink("/trickyfile");		/* removes name from directory tree */

      do {
	    write(f, ....);		/* inode still allocated, so this is
					/* OK */
      until (bored);

      /* / has been filled up! */
      close(f);
      /* all blocks have been freed again */

   Some programmers really do this to avoid writing signal handlers
   to clean up temporary files when the program is aborted (exit() will
   also do the close() if need be).

   But this would mean you'd need a generally (or group) writeable
   directory in the root file system, and/or a setuid root or setgid
   some_group program.  Use find(1) to locate all likely candidates!


ps. please let us know what the final diagnosis proves to be.

>(kerr@oodis01.af.mil)

>Oh yes, /tmp/ is a separate file system, we are running OSx 5.0d.
-- 
Ken McDonell			  E-mail:     kenj@pyramid.com kenj@yarra.oz.au
Performance Analysis Group	  Phone:      +61 3 820 0711
Pyramid Technology Corporation	  Disclaimer: I speak for me alone, of course.
Melbourne, Australia