Thanks for the thoughtful response! On Sun, 2022-01-30 at 18:47 +0100, Steinar H. Gunderson wrote: > On Thu, Jan 20, 2022 at 08:05:14AM -0700, Kevin Locke wrote: >> 2. The error occurred on a CIFS filesystem, which is excluded by >> PRUNEFS in /etc/updatedb.conf. Presumably it should be skipped >> rather than causing an error. > > The problem is that updatedb doesn't really know for sure it entered a new > filesystem until it's stat-ed the directory. [...] > >> 3. updatedb immediately aborts, rather than updating the database for >> the rest of the filesystem. In this case, since the failing mount >> was at the root, the entire tree is skipped. > > I don't honestly think this is a bug. If updatedb goes wrong for whatever > reason, it's not good to just silently discard parts of the database. > If nothing else, the next rescan could become very expensive.
I think the behavior is understandable in both of the above cases, although it's unfortunate that a flakey mount on an excluded filesystem at an otherwise always empty directory causes updatedb to fail entirely. I'm not sure if it might be worth the effort to check /proc/mounts or statfs(2) on stat(2) failure (for certain error codes?), or to consider whether the directory is currently empty in the database, or to skip it without discarding previous entries, or something else. I'll defer to your judgement. It's not a common or major issue for me. Feel free to close or treat as low-priority. I thought it was worth raising the issue for consideration, but don't have strong feelings about it. Cheers, Kevin
