#3 PRUNE_BIND_MOUNTS does not work in some cases
Closed: Fixed None Opened 10 years ago by adeodato.

This comes from Debian [http://bugs.debian.org/458753 bug#458753]:


I have three copies of /home mounted, at /home and
/space/chroot/i686/home and /space/chroot/i686-shared/home.
Both extra copies are bind mounts from /home.

/space/chroot/i686-shared is also a bind mount, from /.
/space/chroot/i686 is a real directory.

locate finds two copies of a file in my home directory. One is in
/home and the other in /space/chroot/i686-shared/home. So
the bind mount in /space/chroot/i686/home was skipped, but not
the one in /space/chroot/i686-shared/home.

Relevant bits of fstab:

/dev/mapper/Root-Home /home ext3 defaults 0 2

/home /space/chroot/i686/home none bind 0 0

/ /space/chroot/i686-shared none bind 0 0
/home /space/chroot/i686-shared/home none bind 0 0

Note: I already sent this bug to Miloslav by private mail. He asked for output of running updatedb with --debug-pruning. I sent it to him, I'm attaching it here again for reference.

Right, sorry for the delay.

Fix path sorting in prunepaths and build mount list

The attached patch should fix the bug. Can you have the original reporter test it, please?

I provided packages to the original submitter, and he confirms that your proposed patch fixes the problem.


P.S.: Do you have an estimate of when the next release will be? Just curious, as to know whether upload a patched mlocate to Debian, or the next release will come in time for our freeze, which will be soon.

Thanks for the results.

This is quite an important bug, so I'd like to do a release this weekend at the latest - but it's possible the release will be delayed.

mlocate-0.21 was released.

Metadata Update from @adeodato:
- Issue assigned to mitr

2 years ago

Login to comment on this ticket.