Mail Archives: cygwin/2004/07/27/22:47:33
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/
- Raw text -