This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
stat_worker patch and suggestion
- To: Chris Faylor <cgf@cygnus.com>
- Subject: stat_worker patch and suggestion
- From: Egor Duda <deo@logos-m.ru>
- Date: Thu, 12 Aug 1999 20:51:23 +0400
- CC: cygwin-developers <cygwin-developers@sourceware.cygnus.com>
- Organization: DEO
- References: <19990812120916.B893@cygnus.com>
- Reply-To: Egor Duda <deo@logos-m.ru>
Hi!
August 12, 1999 Chris Faylor cgf@cygnus.com wrote:
>> Attached patch make stat functions recognize UNC paths as remote. It
>>speeds up fstat operations on remote drives, which are not mapped to
>>drive letters.
CF> Does this patch still operate correctly with the old "\\a" style method
CF> for handling drives?
if you mean paths like \\.\c:\temp\ then answer is "yes" -- it treats
them as local ones. Are there any other possible UNC notation? Current
implementation of stat_worker relies on the fact that first symbol of
win32 name is drive letter. Generally, it's not true.
>>BTW, what do you think of providing porters with some sort of "lite"
>>versions of stat functions? Retrieving all stat information isn't
>>always necessary, and opening file to get it's st_ino and scanning
>>directory to get st_nlinks are quite time-consuming operations.
CF> I don't know how this could be used. Would you define stat as
CF> "stat_lite" when you compile an application?
no, it would be too straightforward. Application may still need to have
st_ino and st_nlinks sometimes. I meant that when porting application
one could choose between slow and informative stat and fast stat_lite,
if application don't need those specific fields. I've tried to
recompile midnight commander replacing stat with stat_lite in
directory-loading code -- it runs several times faster, especially on
slow network drives. Whether to do such substitution global for all
application or not -- it's up to porter.
Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19