Symlinking in win9x is now possible at kernel-level!

Symlinking in win9x is now possible at kernel-level!

[Konstantin Isakov]

  Hello everybody.

Have you ever wanted your symlinks to be followed for *all* Windows
programs, not only for those compiled against cygwin?

You know, I was lacking such capability and I implemented it (in
the form of VxD driver).

I decided to use existing cygwin's symlink file format (used in
older versions of cygwin, newer versions use Windows .lnk, but that
doesn't matter since that doesn't prevent you from creating old-style
symlinks).

Can't say that the implementation is very clear, but it works,
symlinks are really followed for *all* programs! The main and quite
obvious limitation is that the driver I wrote works only in
Windows'9x (and ME possibly)...

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

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

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

-- 
Konstantin Isakov



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

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

[egor duda]

Hi!

Monday, 07 May, 2001 Konstantin Isakov ikm@online.ru wrote:

KI> Can't say that the implementation is very clear, but it works,
KI> symlinks are really followed for *all* programs! The main and quite
KI> obvious limitation is that the driver I wrote works only in
KI> Windows'9x (and ME possibly)...

i hate to play devil's advocate, but there's some points you may wish
to consider.

the problem with "native" symlinks is that many native programs don't
expect them, an can be easily confused. for example, symlinks can
(possibly) be cycled /foo/bar points to /foo, for example. have you
tried such configuration? how about pressing F3 in explorer and
traversing file system?

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

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

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

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

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

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

[Konstantin Isakov]

Monday, May 07, 2001, 11:45:46 PM, you wrote:

KI>> Can't say that the implementation is very clear, but it works,
KI>> symlinks are really followed for *all* programs! The main and quite
KI>> obvious limitation is that the driver I wrote works only in
KI>> Windows'9x (and ME possibly)...

ed> i hate to play devil's advocate, but there's some points you may wish
ed> to consider.

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

I know. It is the biggest problem. So you will have to think whether
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?

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

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.

The idea is to add similar API to the driver. I can do it.
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?

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

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?

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


-- 
Konstantin Isakov



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

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

[egor duda]

Hi!

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



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

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

[Konstantin Isakov]

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.

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

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.


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


-- 
Konstantin Isakov



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

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

[egor duda]

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

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

[Konstantin Isakov]

Tuesday, May 08, 2001, 3:48:54 PM, you wrote:

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

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

It *is* applicable when you need to symlink one file to another for
*all* programs in Windows'9x, not only for cygwin's ports. Is it
really so hard to understand?

ed> well, how about normal cygwin's open() vs. CreateFile()+your driver?

It is exactly what I tested. ~1.2.

If you are intereseted in cygwin' open() + cygwin1.dll + my driver --
it is very slow, two times slower (don't know why, it should be faster).

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

I don't care of speed in this case, it can't be noticed by me in real life anyway.
If you care -- well, I can't help. I wrote that driver just because I need
it. And I thought it could be useful to somebody else. That's all about
this.


-- 
Konstantin Isakov



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