nolan@tssi.UUCP (Michael Nolan) (06/25/91)
Browsing around on my NCR Tower (SVR2) trying to solve a problem with lock files not being deleted by uucico, I discovered that there appear to be two links to a directory, although I had thought that was not permitted in unix. (multiple file links, yes, but not multiple directory links) (ls -ail /usr/spool) total 8 1935 drwxrwxr-x 7 root rootgrp 160 Jun 24 15:42 . 64 drwxr-xr-x 28 bin bin 480 Mar 7 16:44 .. 1936 drwxr-xr-x 4 root sys 64 Jul 18 1988 cron 1984 drwxrwxrwx 16 uucp daemon 384 Jun 24 16:02 locks 1942 drwxr-xr-x 8 lp bin 320 Dec 27 17:09 lp 1980 drwxrwxr-x 3 root rootgrp 144 Feb 12 1990 lpd 1984 drwxrwxrwx 16 uucp daemon 384 Jun 24 16:02 uucp 1997 drwxrwxrwx 2 uucp daemon 96 May 25 03:37 uucppublic Note that both locks and uucp have the same inode number. As one might expect, /usr/spool/locks and /usr/spool/uucp have identical contents. If I create a file in one, it shows up in the other. Is this normal and, if not, is it a serious problem? (Is it causing the LCK..tty07 file not to be deleted after an incoming uucico call?) ------------------------------------------------------------------------------ Michael Nolan "Software means never having Tailored Software Services, Inc. to say you're finished." Lincoln, Nebraska (402) 423-1490 --J. D. Hildebrand in UNIX REVIEW UUCP: tssi!nolan (or try sparky!dsndata!tssi!nolan) Internet: nolan@helios.unl.edu (if you can't get the other address to work)
cpcahil@virtech.uucp (Conor P. Cahill) (06/25/91)
nolan@tssi.UUCP (Michael Nolan) writes: >Browsing around on my NCR Tower (SVR2) trying to solve a problem with lock >files not being deleted by uucico, I discovered that there appear to be two >links to a directory, although I had thought that was not permitted in unix. >(multiple file links, yes, but not multiple directory links) The superuser can create links to directories using the link command. While this is "permitted", I would strongly recommend against it because it can cause problems with programs like find(1) which walk around the system by cding into a directory and then cding to ... > 1984 drwxrwxrwx 16 uucp daemon 384 Jun 24 16:02 locks > 1984 drwxrwxrwx 16 uucp daemon 384 Jun 24 16:02 uucp since these are both withing the same parent directory, they won't exhibit the problems I mentioned with respect to file tree walking. >Is this normal and, if not, is it a serious problem? I don't know if it is normal for the NEC, but it is not normal for standard AT&T SV. > (Is it causing the >LCK..tty07 file not to be deleted after an incoming uucico call?) I doubt it because a program *probably* wouldn't notice that they are linked. -- I guess these are the views of VTI - since it is my consulting company. Conor P. Cahill (703)430-9247 uunet!virtech!cpcahil Virtual Technologies, Inc. 46030 Manekin Plaza Sterling, VA 22170
tom@itc.univie.ac.at (Tom Kovar) (06/25/91)
In article <2030@tssi.UUCP> tssi!nolan writes: >Browsing around on my NCR Tower (SVR2) trying to solve a problem with lock >files not being deleted by uucico, I discovered that there appear to be two >links to a directory, although I had thought that was not permitted in unix. >(multiple file links, yes, but not multiple directory links) Not so fully true. The superuser may generate directory hard links (see link(2v)); if not, it would not be possible to have the . and .. entries in the directory :-) Tom
gwc@root.co.uk (Geoff Clare) (06/28/91)
tom@itc.univie.ac.at (Tom Kovar) writes: > The superuser may generate directory hard links (see >link(2v)); if not, it would not be possible to have the . and .. entries >in the directory :-) Not true. The links to . and .. can be created by a mkdir() system call, in which case there is no need for link() to be able to link directories. -- Geoff Clare <gwc@root.co.uk> (Dumb American mailers: ...!uunet!root.co.uk!gwc) UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273