Date: Wed, 17 Oct 2007 10:35:10 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Stefan Esser <se@FreeBSD.org> Cc: cvs-src@FreeBSD.org, Ceri Davies <ceri@submonkey.net>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/locate/locate updatedb.sh Message-ID: <20071017103509.GA71990@FreeBSD.org> In-Reply-To: <4714F06B.7070702@FreeBSD.org> References: <200710152209.l9FM9Jv3017150@repoman.freebsd.org> <20071016102013.GE23043@submonkey.net> <4714F06B.7070702@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 16, 2007 at 07:10:03PM +0200, Stefan Esser wrote: > Ceri Davies schrieb: > > On Mon, Oct 15, 2007 at 10:09:19PM +0000, Stefan Esser wrote: > >> se 2007-10-15 22:09:19 UTC > >> > >> FreeBSD src repository > >> > >> Modified files: > >> usr.bin/locate/locate updatedb.sh > >> Log: > >> Make the updatedb script installed as /usr/libexec/locate.updatedb > >> inspect all local file systems, not only ufs and ext2fs. A number > >> of local file systems has been added over time, and at least zfs > >> has the potential to become a popular choice. Without this change > >> a ZFS root file system causes the script to ignore all file-systems > >> and leads to an empty locate db. (An alternative is to add all the > >> relevant file systems individually, which means that at least zfs, > >> xfs, ntfs, ntfs-3g, msdosfs should be added, probably more). > > > > This now includes /dev, /dev/fd, /proc, /compat/linux/proc, CD-ROMs and DVDs > > as well as duplicating everything in nullfs mounts, all of which are probably > > undesirable -- well, they are undesirable to me; whether they are to > > others is the question ;-). > > Ok, thank you for the information. I did not notice this in my tests. > > I'm not sure what the "local" pseudo fs-type is meant to be used for. > Currently it appears to be identical to "not-remote" (which is what > the locate db update tries to avoid, due to high network load and > scan time). > > I plan to fix this within the next 24 hours (if anybody thinks it needs > to be backed-out immediately, I'm willing to do this, but I'd rather > put in the correct fix instead. > > Two possibilities: We could have another pseudo fs-type in find, which > selects "real" file systems (and skips devfs, procfs, fdescfs, nullfs > and probably more). Scanning of removable devices is dubious, too, > independently of their file system. By selecting "local" and "disk > based" file systems (which would omit not only the pseudo file-systems > and nullfs, but also cd9660 and udf), no specific file systems needed > to be put into the script (and find would have the knowledge). > > The second possibility is to extend the list in the update script. It > needs to contain at least: > > ufs ext2fs zfs > > and probably also: > > xfs msdosfs ntfs ntfs-3g (?) It might be a good idea to drop msdosfs off of this list. Real physical filesystems in Windoze world are typically NTFS now, and FAT is used mainly in removable storage. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017103509.GA71990>