Re: locate.updatedb breaks on inaccessible smbfs mounts

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Sascha Wildner wrote:

> Bill Hacker wrote:
>
> > Not a bug.
> >
> > Regardless of UFS or {whatever} fs type, if *any* mount-point will 
> > contain
> > removable media or potentially unavailable networked resources.
> >  (NFS, SMB, AFS, TVS, CD & DVD formats/ devices, etc.)
> > ..... it should be excluded from  traversal.
>
>
> Hi,
>
> /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.
>
> Sascha

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

Best,

Bill


[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 
detach/re-attach.
Had to import 'mount' and 'umount' from UNIX-land, as OS/2 had no such 
critters....