Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Date:	Tue, 8 May 2001 15:48:54 +0400
From:	egor duda <deo AT logos-m DOT ru>
X-Mailer:	The Bat! (v1.45) Personal
Reply-To:	egor duda <cygwin AT cygwin DOT com>
Organization:	deo
X-Priority:	3 (Normal)
Message-ID:	<85685360846.20010508154854@logos-m.ru>
To:	Konstantin Isakov <ikm AT online DOT ru>
CC:	cygwin AT cygwin DOT com
Subject:	Re: Symlinking in win9x is now possible at kernel-level!
In-reply-To:	<14914348342.20010508152058@online.ru>
References:	<2691945242 DOT 20010507230959 AT online DOT ru>
	<183627572852 DOT 20010507234546 AT logos-m DOT ru> <1545358323 DOT 20010508125109 AT online DOT ru>
	<38678244083 DOT 20010508135017 AT logos-m DOT ru> <14914348342 DOT 20010508152058 AT online DOT ru>
Mime-Version:	1.0

Hi!

Tuesday, 08 May, 2001 Konstantin Isakov ikm AT online DOT ru wrote:

KI> Tuesday, May 08, 2001, 1:50:17 PM, you wrote:

ed>>>>  for example, symlinks can
ed>>>> (possibly) be cycled /foo/bar points to /foo, for example. have you
ed>>>> tried such configuration? how about pressing F3 in explorer and
ed>>>> traversing file system?

KI>>> It won't die just because there is a limit of the expansion count, so
KI>>> it will end up traversing somewhere in /foo/bar/bar/bar/bar/bar/bar ;)

ed>> not so simple. imagine now that you have /foo/bar -> /foo and /foo/baz -> foo
ed>> traversing time will grow exponentially at a rate of 2^n.

ed>> folder sizes will be rather big too.

KI> Of course. I don't want to say all native programs will run correctly.
KI> But some of them will and in fact they do. The ability to turn
KI> symlinking on/off dynamically allows all programs running properly
KI> (but gives a headache for the user who has to turn them on/off ;)

some programs may fail is some subtle way, making administration of
such system rather painful. so, while being quite interesting from
theoretical point of view, it's hardly applicable in real-life
situations. 

ed>> cygwin symlinks are _slow_. i believe cygwin's symlink handling code
ed>> is one of the biggest contributors to the cygwin being slower than
ed>> normal unices. that's why i've asked you about performance. if your
ed>> implementation gives significant speed gain, it's worth adding to
ed>> cygwin in some way.

KI> I have tested it, my implementation is ~1.2 times slower than cygwin's one.
KI> So, the answer is: it isn't.

well, how about normal cygwin's open() vs. CreateFile()+your driver?
please note, that you shouldn't use either on the same file several
times. if you open the same file again and again, disk cache will mute
the results.

i don't expect big performance gain, because both approaches require
reading first bytes of file, which may reside far away from the
directory entry itself. but, i think that CreateFile()+driver should
be somewhat faster.

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -