Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Thu, 12 Aug 1999 13:20:04 -0400
From: Chris Faylor <cgf AT cygnus DOT com>
To: Egor Duda <deo AT logos-m DOT ru>
Cc: cygwin-developers <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: stat_worker patch and suggestion
Message-ID: <19990812132004.A1225@cygnus.com>
References: <19990812120916 DOT B893 AT cygnus DOT com> <7869 DOT 990812 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <7869.990812@logos-m.ru>; from Egor Duda on Thu, Aug 12, 1999 at 08:51:23PM +0400

On Thu, Aug 12, 1999 at 08:51:23PM +0400, Egor Duda wrote:
>August 12, 1999 Chris Faylor cgf AT cygnus DOT 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.

No, I meant exactly what I typed:  \\a .  I did not inspect the patch
or the surrounding code to know if this will affect the *old* way
of accessing drives which is still available, if deprecated.

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

I understand what you're proposing.  I don't understand how you are
specifically suggesting implementing it.  Obviously, speeding up
cygwin is good, in general.

We certainly don't want to have two versions of the DLL.  That would
be a nightmare.  So what are you proposing?   Using '#define'? Using
an environment variable?  Setting a global variable in the program
itself?  Linking in a separate stat_lite.o object?  Or...???

cgf