Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!mintaka!bloom-beacon!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.unix.internals Subject: Re: How do you find the symbolic links to files. Message-ID: <1990Nov26.201925.1251@athena.mit.edu> Date: 26 Nov 90 20:19:25 GMT References: <4899@trantor.harris-atd.com> <4900@trantor.harris-atd.com> <1990Nov26.082214.17329@oracle.com> <1990Nov26.150716.7268@specialix.co.uk> Sender: daemon@athena.mit.edu (Mr Background) Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Organization: Massachusetts Institute of Technology Lines: 61 (This is bordering on belonging in comp.unix.programmer rather than comp.unix.internals, but it's close enough to the edge that I see no reason to attempt to shift the discussion into c.u.p, especially since any such attempt will invariably fail miserably. :-) In article <1990Nov26.150716.7268@specialix.co.uk>, jonb@specialix.co.uk (Jon Brawn) writes: |> OK, so thats found all the real links. Reading the subject line, how |> do you find all the *symbolic* links? How do I access a symbolic link |> file to find out that it IS a symbolic link (I mean from within C, I |> assume stat( char *filename ) is going to stat the pointed too file?) The lstat(2) system call (which, at least on my system, appears on the same man page as the stat(2), so it shouldn't have been that difficult for you to find by RTMing {Wow, RTM as a verb! My English teacher would roll over in her grave if she were dead, but she's not.}) "is like stat except in the case where the named file is a symbolic link, in which case lstat returns information about the link, while stat returns information about the file the link references." Furthermore, readlink(2) will read the contents of a symbolic link so that you can find out where it actually points to. |> Does 'find' have a wonderful flag for finding symlinks? Well, my version of find (4.3 BSD) allows you to use "-type l" to search for files that are symbolic links. It does not, however, provide any facility for reading the contents of the link. It also doesn't follow links -- they are treated as files, and where they point to is irrelevant. I believe that there are other versions of find that do things differently. |> Do any of ncheck/icheck/dcheck/fsck/fsdb/anything understand them? For ncheck, icheck, dcheck, and fsck, the answer is almost certainly no -- a symbolic is just treated as a file with an extra bit set in the inode; that bit is ignored for the purpose of filesystem consistency checks and path tracing of the type that ncheck, icheck, dcheck, and fsck do. I would suspect that this is also the case for fsdb, although I've never used it so I don't know for sure. |> Also, what about old crusties like 'tar' and 'cpio'? What do they do? |> I assume they use good old fashioned stat (not having src I can't check), |> so aren't they going to be conned into making actual files instead of |> symbolic links?????? (Oh mummy! I don't like the sound of that!) *Smart* versions of tar and cpio will use lstat instead of stat so that they can detect and correctly archive symlinks, the same way that tar detects hard links and recreates them when extracting an archive. When a vendor adds symbolic links to their filesystem and then forgets to update things like tar and cpio to understand them, they are just being stupid. I believe that most systems that have symlinks also have a version of tar that supports them, but there are some systems that have symlinks but don't have a version of cpio that understands them. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710