find-utils: updatedb/locate scripts

[linda w]

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/