[Fwd: find-utils: updatedb/locate scripts]

[Fwd: find-utils: updatedb/locate scripts]

[linda w]

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.

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?

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.

But after 1h:45m cpu time, find still hasn't quite indexed my
entire network...:-) part of which is because it doesn't seem to
recognize a softlinks over SMBFS and know not to follow it
rather than just list it (not using "-follow")

-linda




-- 
    In the marketplace of "Real goods", capitalism is limited by safety
    regulations, consumer protection laws, and product liability.  In
    the computer industry, what protects consumers (other than vendor
    good will that seems to diminish inversely to their size)?



--
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/

Re: [Fwd: find-utils: updatedb/locate scripts]

[Igor Pechtchanski]

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 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).

> 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).

> But after 1h:45m cpu time, find still hasn't quite indexed my
> entire network...:-) part of which is because it doesn't seem to
> recognize a softlinks over SMBFS and know not to follow it
> rather than just list it (not using "-follow")

This is most likely a separate problem.  There are issues with symlinks on
SMB shares due incorrect hidden/system attributes.

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
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/

Re: 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/

Re: 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


-- 
    In the marketplace of "Real goods", capitalism is limited by safety
    regulations, consumer protection laws, and product liability.  In
    the computer industry, what protects consumers (other than vendor
    good will that seems to diminish inversely to their size)?



--
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/

Re: find-utils: updatedb/locate scripts

[Larry Hall]

At 10:47 PM 7/27/2004, you wrote:

>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...
>


It's more than kludgey.  *Any* cygwin mount can be a 'system' mount or
a 'user' mount.  So the mounts that are now reporting 'user' for you 
could be changed to return 'system' by simply remounting them as 
'system' mounts and vice versa.  See 'man mount' for more details.



--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/