[net.bugs] bug in du

sys (04/20/83)

The problem stated is that for a directory with some large unknown number
of files, only the directory size was reported, rather than the sum of it's
childrens sizes.

The magic number here is 2048.  If you have that many or more entries in
a directory (including deleted entries), du will not search the directory,
nor will find(1) recurse down into that directory.  well, it happens that
2048*16=32768 = 2^15 which is greater than 2^15-1, the largest number
you can put into a 16 bit signed integer.  It seems that we have some
code like: (there are a couple of lines between them)

	dirsize = statb.st_size;
	for(offset = 0; offset < dirsize; offset += 512) {

Well, it seems that both dirsize and offset are declared to be ints,
but statb.st_size is declared to be of type off_t.  so if statb.st_size
is > 2^15, dirsize  becomes negative, thus the loop is never entered.

This bug is very simple to fix.  In both du.c and find.c, in the function
descend(), change the declarations of dirsize and offset from int to off_t.
On VAXes an int is 32 bits, so it shouldn't matter, but you probably
should change it just to make things look right.
		-Dave Borman
		ihnp4!stolaf!borman

lab (04/21/83)

So find(I) and du(I) will blow up if you have 2048 entries in your
directory (though some may be deleted)...

At a former place of employment (several UNIX systems), there was
a user who had all of his files in his login directory - no
subdirectories. There were hundreds of files there. Whenever he
accessed his files, the system practically ground to a halt. When
some of us hacks found this out, we got the administrator to get
him to change his act. He did leave one legacy: his login, "hwy,"
led to the designation of such monstrosities as "highway-sized
directories," or simply "highways."

One should not wait for find or du to blow up. A directory that
needs indirect addressing in the filesystem is big enough.
Anything approaching highway-size should have the owner blown up
(via disassociation of particles or whatever).

				Larry Bickford
				decvax!decwrl!qubix!lab