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/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,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/
