I do not understand why find is skipping the /opt directory. This is my find that I am using. Using an old sunos server if that matters.
find / -name "*elg222.ini*" 2>/dev/null
/export/elg222.ini
It ignored this. I was able to use vi to open it.
/opt/utils/job/ftp/ini/elg222.ini
Are permissions such on all the directories allowing execute access, if not then find may not see the file, likewise if there are any symlinks then you may need to specify to follow those. furthermore , redirecting stderr to dev/null may be hiding relevant details.
Which permissions do you need? I figured if I can open the file in vi I have the needed permissions. I just did this. It did not produce any output.
find /opt/utils -name "*elg222.ini*"
as per my initial post
Accessing /opt/utils/job/ftp/ini/elg222.ini needs x (access) on all the involved directories.
find additionally needs r (browse) permissions on them.
But find should say "permission denied" if an x or r permission is missing, unless errors are supressed by 2>/dev/null
Another aspect is symlinks to directories. find normally does not follow symlinks.
Try find -L ...
You assume it is skipping /opt. But it might be choking on any level, for example /opt/utils/job/ftp.
You might try a find for some other file in that hierarchy, or just -name '*' on the whole /opt, sending to > xx.stdout 2> xx.stderr, and seeing if it complains.
You might ls -ld progressively on /opt /opt/utils, /opt/utils/job, /opt/utils/job/ftp, /opt/utils/job/ftp/ini, /opt/utils/job/ftp/ini/elg222.ini.
One of the great skills to know is how to diagnose issues precisely, because that is a necessary precursor to fixing issues precisely (and quickly, which is important if somebody is paying you for your time).
Also note carefully the point from @munkeHoller : vi follows links (at least the system does it for you). find is grovelling around directories at a whole lower level, and lets you choose whether your priority is the link to the file, or the file itself. And by default, it prioritises the link.
I'm coming into this topic late I know. In addition to what has been said about permissions possibly blocking the search of the tree (that needs checking), I would also suggest that you add the '-print' switch to chuck the results to stdout.
You're not piping this command into another command so:
and do what with it?
You can use -print to see what it's finding to your screen and, if that's a mountain of stuff, redirect that output to a file so that you can inspect and grep it later. Let the error reporting, if any, go there too. It's all part of diagnosing what's going wrong here.
# find / -name '*elg222.ini*' -print
Use such a command to test the output you're getting and investigate why it's not producing what you expect.
It is hidden way down in the small print, but if there would be no other action, -print is the default. find . is the minimal useful command.
In fact, hiding the output is tricky. I went for find . -exec true {} '+'.
Thats it symlinks. Have you seen a directory structure like this before? Directories, symlinks, then ls says directories even though they are symlinks? Why does ls not say they are symlinks? Are they symlinks even though ls does not tell you they are? df also points out the file is located on /export.
: ls -ld /opt
drwxr-xr-x 26 root sys 32 Jun 11 12:41 /opt
: ls -ld /opt/utils
drwxr-xr-x 7 DSTN dstnse 8 Dec 22 2010 /opt/utils
: ls -ld /opt/utils/job
lrwxrwxrwx 1 DSTN dstnse 3 Dec 22 2010 /opt/utils/job -> bin
: ls -ld /opt/utils/job/ftp
lrwxrwxrwx 1 DSTN dstnse 28 Dec 22 2010 /opt/utils/job/ftp -> /export/customer/dstn/ftptbl
: ls -ld /opt/utils/job/ftp/ini
drwxrwxr-x 20 DSTN dstnse 24 Oct 14 15:25 /opt/utils/job/ftp/ini
: ls -ld /opt/utils/job/ftp/ini/elg222.ini
-rw-r--r-- 1 dstntest dstnset 72 Oct 14 15:24 /opt/utils/job/ftp/ini/elg222.ini
: find -L /opt/utils -name "*elg222.ini*"
/opt/utils/job/ftp/ini/elg222.ini
/opt/utils/bin/ftp/ini/elg222.ini
: df /opt/utils/job/ftp/ini/elg222.ini
Filesystem 1024-blocks Used Available Capacity Mounted on
rpool/export 204984105 396500 32778678 2% /export
Does find give up when it reaches a symlink? This search literally took 1 second.
: find -L /opt/utils -name "*elg222.ini*"
A symbolic link is just an alternative name for something else in the file system. The link has its own type, as in find . -type l. The target of a symbolic link can be of any valid type: a file, a device, a directory, a named pipe (FIFO), or another link. The system does not know the type of the target until it finds it. A link can even be to a non-existent name -- it acts the same as if you supplied a wrong name in your command. A "broken" link is not fatal to anything. The only bad thing is if a chain of symbolic links points back to itself somewhere. Typically, the file system chases its own tail for about 40 steps, then reports "too many links".
You might try: find -L /opt/utils -name "*elg222.ini*" -exec stat {} '+'. You should see that the two files it finds are the same file (having the same inode). Because the link /opt/utils/job -> bin gives job a second name, every file below /opt/utils/job has two ways to reach it.
As regards the 1-second search: directory blocks get cached just the same as data blocks. If you do two consecutive searches in the same part of the directory tree (whether you start with absolute or relative starting-points), the second one will usually be way faster (here, about 140 times faster).
$ pwd
/home/paul/Downloads
$ # As sudo: sync; echo 3 > /proc/sys/vm/drop_caches
$ time find . -type f -name 'Excess_Policy Schedule.pdf' -ls
6166297 300 -rw-rw-r-- 1 paul paul 306254 Mar 3 2024 ./Volvo_2024_Insure/Excess_Policy\ Schedule.pdf
real 0m4.161s
user 0m0.027s
sys 0m0.102s
$ time find /home/paul/Downloads -type f -name 'Excess_Policy Schedule.pdf' -ls
6166297 300 -rw-rw-r-- 1 paul paul 306254 Mar 3 2024 /home/paul/Downloads/Volvo_2024_Insure/Excess_Policy\ Schedule.pdf
real 0m0.027s
user 0m0.019s
sys 0m0.009s
$ # As sudo: sync; echo 3 > /proc/sys/vm/drop_caches
$ time find /home/paul/Downloads -type f -name 'Excess_Policy Schedule.pdf' -ls
6166297 300 -rw-rw-r-- 1 paul paul 306254 Mar 3 2024 /home/paul/Downloads/Volvo_2024_Insure/Excess_Policy\ Schedule.pdf
real 0m3.741s
user 0m0.032s
sys 0m0.088s
$
find is a venerable tool that has all the quirks shaken out of it long ago. But it encompasses many aspects of the file systems at a low level, so the man page demands very careful attention.
Thats it symlinks. Thank you for pointing out to use ls -ld. Have you seen a directory structure like this before? Directories, symlinks, then ls says directories even though they are symlinks? Why does ls not say they are symlinks? Are they symlinks even though ls does not tell you they are? df also points out the file is located on /export.
: ls -ld /opt
drwxr-xr-x 26 root sys 32 Jun 11 12:41 /opt
: ls -ld /opt/utils
drwxr-xr-x 7 DSTN dstnse 8 Dec 22 2010 /opt/utils
: ls -ld /opt/utils/job
lrwxrwxrwx 1 DSTN dstnse 3 Dec 22 2010 /opt/utils/job -> bin
: ls -ld /opt/utils/job/ftp
lrwxrwxrwx 1 DSTN dstnse 28 Dec 22 2010 /opt/utils/job/ftp -> /export/customer/dstn/ftptbl
: ls -ld /opt/utils/job/ftp/ini
drwxrwxr-x 20 DSTN dstnse 24 Oct 14 15:25 /opt/utils/job/ftp/ini
: ls -ld /opt/utils/job/ftp/ini/elg222.ini
-rw-r--r-- 1 dstntest dstnset 72 Oct 14 15:24 /opt/utils/job/ftp/ini/elg222.ini
: find -L /opt/utils -name "*elg222.ini*"
/opt/utils/job/ftp/ini/elg222.ini
/opt/utils/bin/ftp/ini/elg222.ini
: df /opt/utils/job/ftp/ini/elg222.ini
Filesystem 1024-blocks Used Available Capacity Mounted on
rpool/export 204984105 396500 32778678 2% /export
Does find give up when it reaches a symlink? This search literally took 1 second.
: find -L /opt/utils -name "*elg222.ini*"
Sorry I was confused by this. I am used to seeing some output like with awk where it clearly tells you that you are looking at a symlink.
: ls -ld /opt/utils/job/ftp/ini/elg222.ini
-rw-r--r-- 1 dstntest dstnset 72 Oct 14 15:24 /opt/utils/job/ftp/ini/elg222.ini
: ls -l /usr/bin/awk
lrwxrwxrwx 1 root root 18 Jul 28 2021 /usr/bin/awk -> ../../usr/bin/nawk
The output was overwhelming with /opt. That is why I switched my search to /opt/utils. Then it changed to giving no output with /opt/utils.
Directories "buried" in a pathname always follow symlinks. Only the last part of a pathname (the target) can be examined by means of an lstat()
The ls and stat commands do that.
find, starting from the given pathname, uses lstat() on each directory it visits.
stat() is like lstat() but follows a symlink before examining the target.
For example, in the shell a [ -r pathname ] uses stat(), a [ -h pathname ] uses lstat()
/opt is used for all the optional software you have installed. Mine has only 94 entries in the whole tree, and 90 of those are in /opt/brother. Not really family -- I installed a Brother DCP-J4110DW about ten years ago. But if your own output is overwhelming, just redirect stdout to a file and grep/view/edit that in stages to suit yourself.
ls -l clearly shows you that the type of the filesystem object /usr/bin/awk is a link, but says (and implies) nothing about what the type or contents of that linked name may be. If it did show you, and it was another link, that pointed to another link ..., where would you expect it to stop? It might also (for example) be a link to something on another file system which is not currently mounted. So the link may change from "broken" to a valid target merely because you inserted a USB drive.
Examining the ls output is only intended for human interpretation. There is nothing to stop me naming a real file as is it were a link.
$ ls -ltr | tail -n 1
-rw-rw-r-- 1 paul paul 38 Oct 16 10:21 Trick -> Halloween
$ cat Trick*
This is not a link, it is a real file
find by default invokes -print and shows you a file name (file in the sense of "any object in a file system"). But if you end the find command with -ls, it will show you everything just like ls, with the addition of an inode number at the start. If you invoke -exec stat on the object, it will tell you everything about that entry in about 8 lines, but it still won't follow the link itself.
Soft links are very common. For example, this is how alternative versions of common tools (like a C compiler) can be installed without disruption. I keep my personal utilities each in their own development directory, but I keep the latest stable version accessible and on my PATH by putting a symbolic link into /home/paul/.local/bin. I receive photos (often duplicates) from family across the globe, and I keep exactly one copy of each image in a year/month file tree, and use soft links to group them under event directories like Jack 2019 Birthday.
df does not knowingly "point out" that the file is on /export. The system blindly follows links until it reaches an actual file (unless it hits a broken link). Then it does its job, which is to report on the file system that contains that file object. It would be a horror if every process that opened a file had to resolve every link it found. There is a specific Kernel system call readlink to examine symbolic links in detail.
I'm a little puzzled. Unix find's tend to have no default action - I first saw that in Gnu find. I habitually use "find / -print" or "find / -ls" to deal with that. You're getting some files, just not all of them, so perhaps you are using Gnu find on SunOS, or SunOS was later (after I stopped using it) changed to match Gnu find's actions.
Welcome @dstromberg !
find in SunOS 4 had no default print.
find in SunOS 5 (Solaris) has the default print.
SunOS 5 started as Solaris 2.
And SunOS 4 was lately named Solaris 1.
IMHO a marketing decision.
SunOS 4 is dead. Today "Solaris" means SunOS 5.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.