This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Symlinking in win9x is now possible at kernel-level!


Hi!

Tuesday, 08 May, 2001 Konstantin Isakov ikm@online.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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]