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 13:50:17 +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: <38678244083.20010508135017@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: <1545358323.20010508125109@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

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

ed>> the problem with "native" symlinks is that many native programs don't
ed>> expect them, an can be easily confused.

KI> I know. It is the biggest problem. So you will have to think whether
KI> any particular program will be confused or not.

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 ;)

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

folder sizes will be rather big too.

ed>> on unix, symlink concept is supported by various system calls,
ed>> lstat(), for instance. win32 lacks them, so native programs may go
ed>> wrong.

KI> The idea is to add similar API to the driver. I can do it.
KI> But of course I can't tell all existing programs that there is now such API :(

ed>> maybe you should make this driver to be available only to programs
ed>> that specifically state that they are able to handle symlinks?

KI> Unfortunately, it doesn't make much sense then. Just because the only
KI> programs I have that know about symlinks are from cygwin package, but
KI> they don't need any foreign symlinking support ;)

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

KI>>> If you need it, you're welcome to download it from
KI>>> http://sourceforge.net/projects/symlink9x

KI>>> Although everything is in pre-alpha state, it has been working
KI>>> for me nicely for a week or two already.

KI>>> Just an announcement, hope I haven't violated any policies ;)

ed>> btw, did you test their performance? is your implementation much
ed>> faster than cygwin's?

KI> I can only say that I can't notice any slowdown at all.

can you test how long does it take to perform cygwin's open() for some
file with symlink components in it's path with/without your driver?

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