1

Yes, I have set updatedb.conf to not prune nfs, cifs, smb, autofs and set prune bind mounts to "no".

PRUNE_BIND_MOUNTS="no"
# PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/tmp /var/spool /home/.ecryptfs /var/lib/schroot"
PRUNEFS="rpc_pipefs afs binfmt_misc proc iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs lustre tmpfs usbfs udf fuse.glusterfs fuse.sshfs curlftpfs ecryptfs fuse

I even get the correct output when checking the --debug-pruning output. Furthermore I use --verbose and tee the output to a indexed_paths.txt file and that txt file contains the files on my other drives.

STILL, when I invoke locate my_video.mp4 it doesn't give me any matches under /media/myusername/, just the things on my bootable drive.

I've tried this on two separate ubuntu 16 installations.

What the (insert expletive) is going on?

The only thing I can think of is my LONG updatedb invocation hasn't finished yet and only when it has does the existing locate.db get replaced. I'm not convinced that that is the real reason because I vaguely recall new files from my bootable disk showing up in the search results even though my updatedb job hasn't finished yet.

Other information

The mount entry looks like this:

/dev/sde1 on /media/myusername/myNtfsDrive type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

I am using the automounter. I hope that's not causing problems.

  • "The only thing I can think of is my LONG updatedb invocation hasn't finished yet and only when it has does the existing locate.db get replaced. I'm not convinced that that is the real reason." Why do you think that's not the real reason? – muru Sep 19 '17 at 4:19
  • I believe that new files on my bootable disk DO show up in the search results. – Sridhar Sarnobat Sep 19 '17 at 4:20
  • And you're sure they couldn't have been indexed by an earlier run? – muru Sep 19 '17 at 4:21
  • I could be wrong. But I'd have thought users would complain if that was the way updatedb actually worked. I thought also I ran updatedb previously and wasn't getting results (though it's possible that the previous command failed after serveral hours - unfortunately I can't go back and find out easily). – Sridhar Sarnobat Sep 19 '17 at 4:23
  • 1
    I'd think it's technically far simpler to update the file in a single go at the end of a run than to read a file that's getting updated as you read it. Given that, if I were the dev, complaining users would have to do the implementation and maintenance of that code for such complaints to be of any weight. – muru Sep 19 '17 at 4:26
1

As @muru said, it turns out that updatedb is a batch updater. My indexing job which was running for about 10 hours just completed and I get results on mounted drives (and previous jobs that I thought succeeded failed unattended).

In case you're wondering why my job takes 10 hours, I have some large terrabyte disks with huge hierarchies (from backing up old computers).

Moral of the story : be patient :)

Followup

I wonder if there's a way to run updatedb on one disk at a time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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