How do I tell when a directory is empty in a script?

[Greg Hunt]

In article <1991Apr3.142150.4445 at athena.mit.edu>, jik at athena.mit.edu (Jonathan I. Kamens) writes:
> In article <1991Mar30.225406.20493 at dg-rtp.dg.com>, hunt at dg-rtp.rtp.dg.com (Greg Hunt) writes:
> |> Telling whether a directory is empty from a script should be possible
> |> by looking at the size of the directory itself.  If the directory size
> |> is zero, then the directory is empty.  Otherwise, it contains some
> |> files.  You should check this out on your system to make sure it holds
> |> true for the flavor of UNIX that you're using.
> 
>   Um, I can't imagine this being true for *any* remotely normal flavor of
> Unix.

Well, DG/UX does it this way, and it's a pretty modern UNIX.  It's
also completely compliant with system 5.4.

>   I just did the following tests on both a BSD-derived and a SysV-derived
> system:
> 
>   1) Create a new, empty directory.  Check its size.  Cd into it and run the
> following:
> 
> 	if [ -s . ]; then
> 		echo "Directory has some files in it."
> 	else
> 		echo "Directory is empty."
> 	fi
>
> and see what happens.

It reports "Directory is empty", just as I expected it to.  That's
because the size of the directory file itself is zero bytes.

>   2) Create a bunch of files in the directory.  Remove them all.  Check the
> directory's size again.

It still reports the size as zero bytes after the files have
been removed, just as expected.

>   In the first case, the size of the newly created directory was non-zero,
> just as I expected, and the if statement printed out "Directory has some files
> in it," although I hadn't added any.  How can the directory be empty when it
> has to store entries for "." and ".." in it?

Some UNIX'es store . and .. in the inode of the directory instead of
as files in the directory.  They look to all the world like hard
links to the current directory and to the parent directory.  They show
up on ls -la listing just as expected.  It makes creating directories
easier.  Some, maybe most from what you're saying, UNIX'es don't do it
this way.  Some do.

>   In the second case, the directory did not shrink when the files were
> deleted.  Directories grow.  I'm not even convinced that fsck shrinks empty
> dirctories; I believe the only way to shrink a directory with lots of empty
> entries in it is to create a new directory, mv the files from the old
> directory into the one one, and remove the old directory.

I'd agree that what you said would be necessary on systems that
don't grow and shrink directory entries dynamically.

>   If you tried what you posted on a system and it worked, I'd be very
> interested in knowing what kind of Unix it was and what type of filesystem
> it's running.  Does it store the "." and ".." directory entries somewhere
> special, or does it fake them without putting them in the filesystem, or does
> "size" mean something special in the context of directories, or what?

It's DG/UX, which is completely compliant with system 5.4.  It runs
the DG/UX filesystem.  The . and .. entries are stored in the inode of
the directory itself.  That makes creating directories easier.  The
size of a directory file means the same thing as it does for other
files, and since . and .. aren't stored as files in the directory,
they don't show up in the space used by the directory.

I was aware that other UNIX'es do things differently, and that's
why I suggested that the person that asked the question try out his
system to see how it functions.  Sorry for all the confusion.

-- 
Greg Hunt                        Internet: hunt at dg-rtp.rtp.dg.com
DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC, USA  These opinions are mine, not DG's.