Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have

link -> file

I do

find -L . -name 'link'

And get


Why is that?

man find says:

-L : Follow symbolic links. When find examines or prints information about files, the information used shall be taken from the properties of the file to which the link points, not from the link itself (unless it is a bro‐ ken symbolic link or find is unable to examine the file to which the link points).

share|improve this question
up vote 10 down vote accepted

The general rule is that if a command operates on links (i.e. directory entries, which are pointers to inodes) then the command treats symlinks as themselves rather than as the object the link points to. Otherwise the command operates on what the symlink points to. Thus cp follows symlinks by default and copies the contents of the file pointed to by the link. But when you ask cp to deal with directory entries by specifying -R, it stops following symlinks. mv always works with directory entries, and so it never follows symlinks.

The find command's normal activity is to operate on directory entries, so symlinks are not followed by default. Adding -L causes find to follow symlinks for all properties except the one that cannot be ignored when doing directory search, the name. One of purposes of find -name is to provide input for commands like mv and rm, which operate on directory entries. There would be unpleasant and surprising results if find -L dir -name could produce names that pointed outside the directory tree rooted at dir.

share|improve this answer
WOW! Why is this subtle concept not well illustrated on man pages (unless I missed it)? This is a big surprise for me. – abc Feb 7 '12 at 20:01

With -L, it examines the properties of the file - contents or metadata, not those of the link. E.g. if you use -atime, it will check the atime of the file, not the link:

$ find testdir/ -name link -newer testdir/ref
$ find -L testdir/ -name link -newer testdir/ref

testdir/link was created after testdir/ref, but the file it points at was not.

share|improve this answer
Can you explain taking my example? What I understand is this: In my example find starts its search. It encounters ./link, since -L is in effect it dereferences it and takes the properties of ./file. It compares name of ./file with pattern 'link' and since it does not match, should not report any o/p. Whats wrong with my reasoning? – abc Feb 7 '12 at 19:08
From the find manual you quoted, "the information used shall be taken from the properties of the file to which the link points." The name of a file is not one of its properties, so it still uses the name of the link. That's also a great deal more useful than the name of the real file. – Kevin Feb 7 '12 at 19:19
"The name of the file is not one of its properties" I did not know that. Any such other attributes of files which are not considered properties? To be honest I am still skeptical and would wait what others have to say. – abc Feb 7 '12 at 19:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.