locate can't find files?

[Karl Auer]

On Sat, 2022-05-14 at 10:54 -0700, MR ZenWiz wrote:
> SOLVED - see below.

Yay!

> I changed the PRUNE... setting from "yes" to "no" and it shows up now
> on the bind mount, but not on /htera.  Apparently placate ismuch
> smarter than mlocate because the former would find both locations -
> the native one and the bound one. plocate only shows one, which is
> perfect.

I still think that's a bit weird. Wouldn't you consider the native one
the "original and best"? Why choose the bound one when you have the
native one? So I did the unthinkable and read the man page again and
found:

   If PRUNE_BIND_MOUNTS is 1 or yes, bind mounts are not scanned
   by updatedb(8). All file systems mounted in the subtree of a
   bind mount are skipped  as well, even if they are not bind
   mounts.

However, there is also this from the mount manpage:

   It is important to understand that "bind" does not to create
   any second-class or special node in the kernel VFS. The "bind"
   is just another operation to attach a filesystem. There is
   nowhere  stored  information that the filesystem has been
   attached by "bind" operation.

So how does updatedb even know a filesystem is a bound one? I think it
might be able to tell from /proc/self/mountinfo or /proc/mounts because
I suspect that a bind mount entry in those places would be missing some
mount information like filesystem type.

It's hard to be sure, but I am guessing that there are three things
going on here. Firstly, it was finding the bind mount, then it was
skipping /htera because it is "a filesystem mounted in the subtree of a
bind mount", and now that it is not doing that it is deduplicating the
references it finds.

It still seems odd to me that it chooses bind mount references over
direct references, but it may just be that it doesn't care and the
result is an artifact, not a choice.

The updatedb command has a "--debug-pruning" command line option that
might throw some light on the process. Don't know if plocate has a
similar one.

Would love to hear from someone who actualy knows what's going on.

Anyway, works now :-)

Regards, K.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: 61A0 99A9 8823 3A75 871E 5D90 BADB B237 260C 9C58
Old fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170