How do you find the symbolic links to files.

[Jonathan I. Kamens]

  (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 at specialix.co.uk>, jonb at 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 at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710