1

I use mdfind extensively to look for files on my file system because it is so much faster than find. In this case, I was looking for README.md files.

But today I just realized I was missing some files because they were actually symlinks.

Let me give you an example:

rm -rf test
mkdir test
cd test
touch foo.md bar.md test.txt test2.txt
ln -s test2.txt zoom.md
cd ..

OK, now if tree it I see:

test
├── bar.md
├── foo.md
├── test.txt
├── test2.txt
└── zoom.md -> test2.txt

and using find test -name "*.md" :

test/bar.md
test/foo.md
test/zoom.md

but mdfind -onlyin test -name md doesn't match the symlink zoom.md:

..../test/test/foo.md
..../test/test/bar.md

From this, it looks like specifying "kMDItemContentType == public.symlink" might help. It didn't.

Looked around some more for kMDItemContentType online, but Apple for some reason provides next to no documentation about mdfind advanced usage.

Improve this question

1 Answer 1

Reset to default
1

The Spotlight index (as used by mdfind) indexes files and folders. But a symlink is not a file. It is a link to a file. It is the file which is indexed.

On the the other hand, an alias is a file and is indexed by Spotlight. Its UTI is com.apple.alias-file.

Unless you are prepared to change your symlinks to aliases, the answer to the question is: No, you can't find symlinks with mdfind.

But you can use find to search for symlinks. For example find . -type l -ls finds all symlinks below the current directory.

Improve this answer
7
  • In Unix and Linux, everything is considered a file including symlinks. It’s just symlinks are a file type that is not indexed by Spotlight.
    – Allan
    Commented Dec 1, 2022 at 23:23
  • Yeah, aside from the "not a file" claim, you're probably right. symlinks seem to be 2nd class citizens to Spotlight. FWIW mdls returns the same metadata for the symlink as for the file. What I've ended doing is inverting which files are real and which symlinks: my organization is to track issues as directories under a certain location with a README.md file. Then I came with a way to generate checklist.md as a reminder of things I needed to fix. So ln -s checklist.md README.md and I've got both my readme and my checklist, right? Wrong, mdfind finds no README.md.
    – JL Peyret
    Commented Dec 2, 2022 at 0:45
  • So, generate checklist as README.md and then ln -s README.md checklist.md. mdfind still finds its files. Still, an annoyance in mdfind. I am well aware of find usage, in fact I used find . -name README.md -type l to identify where I had this problem. The only thing is mdfind is awesomely faster... when it works as expected. I'll leave this out for a while. If no one else contradicts you and has a better solution then I'll accept it later. Upvoted.
    – JL Peyret
    Commented Dec 2, 2022 at 0:48
  • @Allan I am very much not an expert on file systems, but my understanding is that at one time unix systems did store symlinks in files, but that this is no longer true. Most POSIX systems implement fast symlinks and store a pointer in the file system. The size reported for a symlink is the size of the pointer. This simplicity of symlinks is the main advantage over aliases which are stored as files.
    – Gilby
    Commented Dec 2, 2022 at 1:45
  • A symlink is a file object type so the adage “everything is a file in Unix” can and still applies. If you get the inode number of the file (ls -i foo.bar where foo.bar is a symlink) you will see that it’s a valid object and can be treated as such. I think you may be conflating the partitioning scheme (FAT, APFS, NTFS, etc.) and how it maps to files via pointers versus the OS file system and how it handles the objects contained in it’s file system.
    – Allan
    Commented Dec 5, 2022 at 22:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .