Re: find-utils: updatedb/locate scripts

[linda w <cygwin at tlinx dot org>]

Igor Pechtchanski wrote:

> Igor Pechtchanski wrote:
>
>  Linda,
>
> On Tue, 27 Jul 2004, linda w wrote:
>
>
>  
>
> > I generally have updatedb run every night on my win system.
> >
> > But lately it has been having trouble completing and am looking at
> > the whole process and am noticing some oddities.
> >
> > in looking at the find command I see it tries not to look at remotely
> > mounted drives unless they are in the NETWORK_PATHS var -- but on cygwin
> > this isn't working as the updatedb-script authors would have wanted.
> >
> > looking at the file-system type of a file using "find":
> >
> > find / -type d -maxdepth 2 -printf "%p(%F)\n"
> >
> > I see some oddities:
> >
> > 1) /proc seems to return a "fstype" of "unknown"
> > and
> > 2) remotely mounted file systems and CDROMS return an fstype of "user", vs.
> > the local IDE hard drive which returns fstype=system.
> >
> > -----
> > Now this could be coded around, by various prune path statements or by
> > fixing updatedb to know that under cygwin, "user" is a remotefs and
> > "system" is local, but that seems a bit kludgey.
> >    
> This is wrong. You can have local filesystems with type "user". "User"
> simply means a user mount (and "system" means a system one).

I did say it was kludgey, but it might not be a bad idea for updatedb
to only index disks that were system-mounted  ("permanent"?),  disks
anyway and use the NETWORK feature for any smb mounts one wants to
index...

> > I tried to find source on the mirror I normally use, but it doesn't carry
> > source (will have to look further), but I wonder what system call find
> > uses to determine fs-type?
> >    
>
> It uses statfs().  You should be able to just mark the "Src" checkbox for
> the findutils package.  BTW, "df" (from fileutils) also uses the same call
> (try "df -T" sometime).
>  
"Should" != can.  Tried that but the mirror I was using apparently wasn't
carrying source packages and displayed "n/a" when I clicked on source. 
I just have to look a bit further to find a mirror that does have them,
but sounds like source won't do me much good

> > Maybe that system call could return something more appropriate, say:
> > FAT/FAT32/NTFS/network(or SMB/NFS)/cdrom or dvd (or Joliet/iso9660/ufs)
> > etc.? I don't know if that is possible --- just a question.
> >    
> <>
> FWIW, fixing this (i.e., making user/system into flags, and reporting the
> "real" filesystem type) has been on my TODO list for quite some time
> (almost 2 years, see <http://cygwin.com/ml/cygwin/2002-09/msg01035.html>).
> You're welcome to beat me to it (at the pace I'm going, that shouldn't be
> too hard)

I've never been able to get the cygwin source to compile w/o errors, so it
might not be trivial for me.  Seems like the last few times I tried it, it
complained about some include file or another missing....just don't have
all the proper pre-req's loaded I guess -- is there a pre-req list
somewhere?

-l


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/