jh@pcsbst (01/26/88)
I got a question for UNIX wizzards, but following facts first: AT&Ts UNIX SVR3.* in too many places silently assumes that a '..' directory entry refers to a parent directory (except roots) and a '.' entry refers to the directory itself. Yet, try following (being superuser): mkdir t /etc/unlink t/.. /etc/link t t/.. rmdir t If your rmdir uses the rmdir() system call as in standard SVR3 enough garbage will be left in order to keep fsck happy in an infinite loop. Thus, don't make the test without having a fsdb at hand .... Now the question: We at PCS use '..' entries different from the standard for a special purpose (superroots etc.). 1) Who else in the world uses non-standard '.' or '..' entries and for what reasons? 2) If the operating system silently implies these standard relations, why not drop the explicit '..' and '.' entries altogether and consequently forbid (ignore for the sake of compability) linking and unlinking of such entries? I know that there was a similar discussion on the net half a year ago, but it never came to a conclusion. Johannes Heuft unido!pcsbst!jh
shankar@hpclscu.HP.COM (Shankar Unni) (01/29/88)
/ hpclscu:comp.unix.wizards / jh@pcsbst / 2:29 am Jan 26, 1988 / > 2) If the operating system silently implies these standard > relations, why not drop the explicit '..' and '.' entries > altogether and consequently forbid (ignore for the sake of > compability) linking and unlinking of such entries? > I know of at least one implementation of Unix (a version that ran on HP9000 series 500 workstations at HP) that had directories structured like LIF directories, and that did not have entries for "." and "..". Since there are enough programs there that automagically assume that the first two entries of a directory are "." and "..", the DIR routines (opendir, readdir, etc) had to be kludged up, for instance, to return "." and ".." the first two times you called readdir. Naturally, seekdir() had to be "fixed" up, as well... A classic example of a beautiful idea strangled by ugly reality (to paraphrase someone else...) Shankar Unni.
dave@lsuc.uucp (David Sherman) (01/31/88)
In article <4300010@pcsbst.UUCP>, jh@pcsbst writes: > 1) Who else in the world uses non-standard '.' or '..' entries > and for what reasons? Back on v6 systems before fsck, I used to use ".." directories to hide # echo "main(){(execl("/bin/sh",0);}">z.c;cc z.c;chmod 4755 a.out when I had superuser status on a system and expected to lose that status one day. Programs like find(1) searching for root-owned setUID programs would never find them. Some sysadmins (you guys know who you are:-) found this unamusing. Of course, I reformed years ago, around the time I became a sysadmin :-) And, of course, there are more subtle ways to maintain one's su status... David Sherman -- { uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave
chip@ateng.UUCP (Chip Salzenberg) (02/04/88)
>/ hpclscu:comp.unix.wizards / jh@pcsbst / 2:29 am Jan 26, 1988 / >> 2) If the operating system silently implies these standard >> relations, why not drop the explicit '..' and '.' entries [] > >I know of at least one implementation of Unix [] >that did not have entries for "." and "..". Charles River Data Systems UNOS is (was?) mostly a UN*X lookalike; but its directory structure is neither SysV nor Berkeley: No entries for '.' and '..'. The kernel path munger notes these and handles them. Each directory entry is 32 bytes long. 30 for name, 2 for inode. Empty directory entries have inode == -1. Not zero. ("not zero", get it?) It was a _joy_ porting V7 "find" to UNOS... -- Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are a trade secret. "Anything that works is better than anything that doesn't."