Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 X-Mailer: The Bat! (v1.45) Personal Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <85685360846.20010508154854@logos-m.ru> To: Konstantin Isakov 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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