Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 3 Jun 2002 21:55:34 +0200
From: Pavel Tsekov <ptsekov AT gmx DOT net>
Reply-To: Pavel Tsekov <ptsekov AT gmx DOT net>
X-Priority: 3 (Normal)
Message-ID: <1373896452.20020603215534@gmx.net>
To: cygwin AT cygwin DOT com
Subject: Re[2]: The road to 1.3.11 -- please try the latest snapshot
In-Reply-To: <20020601024819.GA22455@redhat.com>
References: <20020530032207 DOT GA29644 AT redhat DOT com>
 <07748651 DOT 20020530131138 AT syntrex DOT com> <20020601024819 DOT GA22455 AT redhat DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Christopher,

Saturday, June 01, 2002, 4:48:19 AM, you wrote:

[snip]

>>2. Deleting a directory under /proc/registry/ takes
>>enormous time if this directory has subdirectories. I tried to
>>trace with strace since first I thought that some kind of infinite
>>loop causes this behaviour, but then it turned out that "rm" is actually
>>working - it just takes too much time to complete ... Most of the time
>>is spent in the cygwin internal path conversion routines, trying to
>>convert the POSIX path representation of the registry key/data into
>>Win32 path name.
>>
>>Yes, I know this is read-only file system :)

CF> I didn't look at this one.  Maybe Chris J will have some insight.

Here is something else I want to share - it may be connected to the
above problem, though I think its not (or not entirely).

Anyone who wants to experience it can try this:
ls -l /proc/registry/HKEY_CLASSES_ROOT

The point is to select a key (directory) with many entries under it.

This takes an enormous time to complete - I've debugged the problem
and I think I've found the culprit though I'm not sure about the
solution. The problem lies in fhandler_registry::exists - this is
called by fhandler_registry::fstat, which is called by stat_worker.
ls -l uses lstat call to gather various information about the directory
components it processes - this is why the problem would show only if one
passes the -l option and not otherwise.

So, fhandler_registry::exists() will call RegEnumKeyEx until it exausts
all entries in a given directory, hits an error or it finds the entry it is
looking for... The whole search is done for every single entry from the
beginning... So consider that you have 3000+ entries in HKEY_CLASSES_ROOT
(as on my machine)...

Ok now - there is this comment in at the start
fhandler_registry::exists().. Could someone sched more light (Chris J
maybe :) ) why is this necessary ? Any links pointers would be
appreciated... I havent searched too hard the MSDN but there doesnt
seem to be too much info on the securiy of the registry :(

Here is the comment I refer to:

/* Returns 0 if path doesn't exist, >0 if path is a directory,
 * <0 if path is a file.
 *
 * We open the last key but one and then enum it's sub-keys and values to see if
 the
 * final component is there. This gets round the problem of not having security
access
 * to the final key in the path.
 */


So if we could avoid the RegEnumEntryEx thing i.e. just use
RegOpenKeyEx this would speed up the process very much.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/