Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!usc!ucla-cs!heather
From: heather@maui.cs.ucla.edu (Heather Burris)
Newsgroups: comp.unix.wizards
Subject: Re: Dot files always first in directory?
Message-ID: <23628@shemp.CS.UCLA.EDU>
Date: 5 May 89 16:08:39 GMT
References: <11108@bloom-beacon.MIT.EDU> <535@biar.UUCP>
Sender: news@CS.UCLA.EDU
Reply-To: heather@cs.ucla.edu (Heather Burris)
Organization: UCLA Computer Science Department
Lines: 44

In article <535@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes:
>In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>>It it safe to assume when writing a program which manipulates
>>directories that . and .. will always be the first two entries in a
>>directory?
>
>No.  It isn't safe to make this assumption.  Even if it is true on your
>machine, it may not be on another implementation (it isn't on my Xenix
>box, according to a quick test using ``l''), and it surely will be changed
>_just_to_smite_your_program_ at some time in the future.

This and other answers about why it isn't safe to assume that . and .. are
first in the directory are correct, but they are correct for the wrong
reasons.  There are two reasons that I can think of for why it is not safe 
to assume that . and .. are first:

	1) The basic reason, true on all UNIX systems that I know of,
	is that . and .. are links and because of file system damage they
	could be removed.  Therefore it is not safe to skip the first
	two directory entries blindly.

	2) The second reason is portability.  On current BSD systems, mkdir
	is a system call and is an atomic operation and therefore assuming
	that . and .. are always present and always first is pretty safe.  
	However, on older UNIX systems, a mkdir is done by using mknod() 
	and then linking in . and .. to the new directory; 3 seperate
	system calls. If the mkdir command were to be interrupted by a 
	system crash, . and .. would not get linked in.  Not all fsck's 
	check for . and .. so a directory can be missing these permanently.  
	Also, to patch up a damaged filesystem, the super user can manually
	link in . and/or .. and then these entries would get whereever
	there is an open spot in the directory and not necessarily at the
	beginning.

The reasons given about using ls to check what could come before . and
.. (and giving examples of characters that would come before . in the
ASCII sorting sequence) are bogus, because ls sorts the directory before
printing it.  If you want to see the "real" order of directory entries, 
i.e. the order that readdir() will present, use the command:

	od -c <directory name>


Heather Burris, UCLA