locate.updatedb breaks on inaccessible smbfs mounts

Bill Hacker wbh at conducive.org
Sat Mar 12 23:36:22 PST 2005

Sascha Wildner wrote:

Bill Hacker wrote:

Not a bug.

Regardless of UFS or {whatever} fs type, if *any* mount-point will 
removable media or potentially unavailable networked resources.
 (NFS, SMB, AFS, TVS, CD & DVD formats/ devices, etc.)
..... it should be excluded from  traversal.


/usr/libexec/locate.updatedb already does exclude all fs types except 
ufs (see its ${FILESYSTEMS} variable) so there should be no need to add 
those smbfs shares' mount points to ${PRUNEPATHS} as well.
A valid move in 'legacy' *BSD, But I see two 'opportunities'
for improvement, as:
A) Even UFS can be on not-always-present resources (FW-2 attached here). [1]

B) Other FS may be on 'permanent' attachment (XFS, JFS, AFS, TVFS)
 - or not...  and DragonFlyBSd in particular is aming to handle
shall we say 'flexible' distributed resources.
- so I suspect the 'except ufs' will become less appropriate.

Rumko's problem here is that even though find is invoked with '! \( 
-fstype ufs \) -prune' it will die anyway when a smbfs share is 
unavailable. This looks like a bug and is independent of locate.updatedb.


I am not in a position (or mindset) to dispute that part...  ;-)



[1] As was hpfs and hpfs-386 here for years - cartidge SCSI, MO and Zip.
And hpfs is possible the most fragile of fs ever w/r unexpected 
Had to import 'mount' and 'umount' from UNIX-land, as OS/2 had no such 

More information about the Bugs mailing list