Subject: Re: v18 vs v17 compile times....
From: [email-masked] ("Wei Ku")

25 May 1997 07:05:15 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01BC68B8.7148D140"
X-Mailer: Microsoft Outlook Express 4.71.0544.0
Original-To: <[email-masked]>
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Original-Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01BC68B8.7148D140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I like your idea very much.
Sincerely,
Wei Ku

***************************************
Department of Physics and Astronomy
The University of Tennessee
1408 Circle Drive
Knoxville, Tennessee 37996-1200
[email-masked]
---------------------------------------
Solid State Division
Oak Ridge National Laboratory
P.O.Box 2008
Oak Ridge, TN 37831-6032
Phone: (423) 574-5795
Fax: (423) 574-4143
[email-masked]
***************************************

 ----
From: Michael Condict <[email-masked]>
To: Sergey Okhapkin <[email-masked]>
Cc: [email-masked]; [email-masked]'; [email-masked]
Date: Sunday, May 25, 1997 2:55 AM
Subject: Re: v18 vs v17 compile times....

In message <[email-masked]>, you write:
> > Somebody else already asked, but I did not see the answer to the =
question, "Is
> > it (reasonably) easy to build without or turn off symbolic links?"
>
> I've made some improvements in symlink checking and sent a patch to =
mr.
> Noer. My patch checks "system" file attribute symlinks must to have. =
It
> doesn't affect non-cygwin programs any way - they knows nothing about
> symlinks.

Isn't the performance problem with symlinks inherent in the current
design?  They are files without a suffix, therefore without an
identifiable Windows type.  Therefore you have to look at the contents
of the file to see if it is a symlink.  And checking the system
attribute is not a complete solution to the performance problem.  It
just means that you don't have to check the contents of the file unless
it has the system attribute.  But you still have to always perform an
extra operation to check the system attribute.  And for the many non-
symlink files that have the system attribute, you still have to read
the file to see if it's a symlink.

I'd like to step back and point out that Windows 95 / NT 4 already =
*have*
symlinks.  They are ".lnk" files for folders, data files and Win32 =
programs,
and ".pif" files for 16-bit programs.  They have all the power of UNIX
symlinks in what information is stored in them, and more.

Now it's true that Windows makes very poor use of these symlinks,
allowing them to have meaning only if you double-click on them in an
Explorer window or feed them to the "Run" menu or the "start" command.
You can't "cd" through them or print the contents of the file to which
they point using the "type" command.  But this is no reason that Cygnus
Win32 can't endow them with the full power of UNIX symlinks.  This would
be a solution that does not require reading a symlink file.

It's also much better integrated with Windows.  Wouldn't it be nice if
you could navigate through Cygnus Win32 symlinks using Explorer?  When
you've made c:/bin be a symlink/shortcut to the Cygnus godawfully named
".../H-i386-cygwin32/bin" directory, wouldn't it be nice if you could
type e.g. "/bin/bash" to the Start / Run window, and have it start up
bash?

Here are some details of how such links could work:

1) Readdir, when returning the names of files in a directory,
   should delete the suffix ".lnk" or ".pif", if present.

2) In the open syscall, if an attempt to open a file fails with
   a "not found" error, open should suffix ".lnk" and try
   again.  If that fails, it should suffix ".pif" and try
   again.  If either of these succeeds, open should then read
   the shortcut file, find the path name of the target, and do a
   Win32 open of the target file.  This will slow down the
   processing of sym links a bit (because a failed open has to
   take place first), but allows non-symlink files to be
   processed without any overhead added by the symlink code.

3) The other syscalls that take a pathname and are supposed to
   follow symlinks (e.g. chdir, stat), should select the target
   file or folder similarly to the algorithm used by open.

Comments?

Michael Condict [email-masked]
The Open Group Research Inst. (617) 621-7349
11 Cambridge Center
Cambridge, MA 02142
-
For help on using this list (especially unsubscribing), send a message =
to
"[email-masked]" with one line of text: "help".

------=_NextPart_000_01BC68B8.7148D140
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<HTML><META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR>

</HEAD>
<BODY>
<P><FONT face=3DArial size=3D2><FONT size=3D2>I like your idea very=20
much.</FONT></FONT>

<P><FONT face=3DArial size=3D2><FONT size=3D2>Sincerely,<BR>
Wei Ku<BR>
<BR>
***************************************<BR>
Department of Physics and Astronomy<BR>
The University of Tennessee<BR>
1408 Circle Drive<BR>
Knoxville, Tennessee 37996-1200<BR>
<A =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=

---------------------------------------<BR>
Solid State Division<BR>
Oak Ridge National Laboratory<BR>
P.O.Box 2008<BR>
Oak Ridge, TN 37831-6032<BR>
Phone: (423) 574-5795<BR>
Fax: (423) 574-4143<BR>
<A =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=

***************************************<BR>
</FONT>

<P></P>
 ----<BR>
<B>From: </B>Michael Condict &lt;[email-masked]&gt;<BR>
<B>To: </B>Sergey Okhapkin &lt;[email-masked]&gt;<BR>
<B>Cc: </B>[email-masked]; [email-masked]'; =
[email-masked]<BR>
<B>Date: </B>Sunday, May 25, 1997 2:55 AM<BR>
<B>Subject: </B>Re: v18 vs v17 compile times....<BR>
<BR>
<HTML><BODY><FONT size=3D2>In message &lt;<A=20
href=3D"mailto:[email-masked]">01BC669C.7C655=
[email-masked]</A>&gt;,=20
you write:<BR>
&gt; &gt; Somebody else already asked, but I did not see the answer to =
the=20
question, &quot;Is<BR>
&gt; &gt; it (reasonably) easy to build without or turn off symbolic=20
links?&quot;<BR>
&gt;<BR>
&gt; I've made some improvements in symlink checking and sent a patch to =
mr.<BR>
&gt; Noer. My patch checks &quot;system&quot; file attribute symlinks =
must to=20
have. It<BR>
&gt; doesn't affect non-cygwin programs any way - they knows nothing =
about<BR>
&gt; symlinks.<BR>
<BR>
Isn't the performance problem with symlinks inherent in the current<BR>
design?&nbsp; They are files without a suffix, therefore without an<BR>
identifiable Windows type.&nbsp; Therefore you have to look at the =
contents<BR>
of the file to see if it is a symlink.&nbsp; And checking the system<BR>
attribute is not a complete solution to the performance problem.&nbsp; =
It<BR>
just means that you don't have to check the contents of the file =
unless<BR>
it has the system attribute.&nbsp; But you still have to always perform =
an<BR>
extra operation to check the system attribute.&nbsp; And for the many =
non-<BR>
symlink files that have the system attribute, you still have to read<BR>
the file to see if it's a symlink.<BR>
<BR>
I'd like to step back and point out that Windows 95 / NT 4 already =
*have*<BR>
symlinks.&nbsp; They are &quot;.lnk&quot; files for folders, data files =
and=20
Win32 programs,<BR>
and &quot;.pif&quot; files for 16-bit programs.&nbsp; They have all the =
power of=20
UNIX<BR>
symlinks in what information is stored in them, and more.<BR>
<BR>
Now it's true that Windows makes very poor use of these symlinks,<BR>
allowing them to have meaning only if you double-click on them in an<BR>
Explorer window or feed them to the &quot;Run&quot; menu or the=20
&quot;start&quot; command.<BR>
You can't &quot;cd&quot; through them or print the contents of the file =
to=20
which<BR>
they point using the &quot;type&quot; command.&nbsp; But this is no =
reason that=20
Cygnus<BR>
Win32 can't endow them with the full power of UNIX symlinks.&nbsp; This=20
would<BR>
be a solution that does not require reading a symlink file.<BR>
<BR>
It's also much better integrated with Windows.&nbsp; Wouldn't it be nice =
if<BR>
you could navigate through Cygnus Win32 symlinks using Explorer?&nbsp; =
When<BR>
you've made c:/bin be a symlink/shortcut to the Cygnus godawfully =
named<BR>
&quot;.../H-i386-cygwin32/bin&quot; directory, wouldn't it be nice if =
you=20
could<BR>
type e.g. &quot;/bin/bash&quot; to the Start / Run window, and have it =
start=20
up<BR>
bash?<BR>
<BR>
Here are some details of how such links could work:<BR>
<BR>
1) Readdir, when returning the names of files in a directory,<BR>
&nbsp;&nbsp; should delete the suffix &quot;.lnk&quot; or =
&quot;.pif&quot;, if=20
present.<BR>
<BR>
2) In the open syscall, if an attempt to open a file fails with<BR>
&nbsp;&nbsp; a &quot;not found&quot; error, open should suffix =
&quot;.lnk&quot;=20
and try<BR>
&nbsp;&nbsp; again.&nbsp; If that fails, it should suffix =
&quot;.pif&quot; and=20
try<BR>
&nbsp;&nbsp; again.&nbsp; If either of these succeeds, open should then =
read<BR>
&nbsp;&nbsp; the shortcut file, find the path name of the target, and do =
a<BR>
&nbsp;&nbsp; Win32 open of the target file.&nbsp; This will slow down =
the<BR>
&nbsp;&nbsp; processing of sym links a bit (because a failed open has =
to<BR>
&nbsp;&nbsp; take place first), but allows non-symlink files to be<BR>
&nbsp;&nbsp; processed without any overhead added by the symlink =
code.<BR>
<BR>
3) The other syscalls that take a pathname and are supposed to<BR>
&nbsp;&nbsp; follow symlinks (e.g. chdir, stat), should select the =
target<BR>
&nbsp;&nbsp; file or folder similarly to the algorithm used by open.<BR>
<BR>
Comments?<BR>
<BR>
Michael Condict <A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR>
The Open Group Research Inst. (617) 621-7349<BR>
11 Cambridge Center<BR>
Cambridge, MA 02142<BR>
-<BR>
For help on using this list (especially unsubscribing), send a message =
to<BR>
&quot;<A=20
href=3D"mailto:[email-masked]">[email-masked]=
</A>&quot;=20
with one line of text: &quot;help&quot;.<BR>
</FONT></FONT>
</BODY></HTML>

------=_NextPart_000_01BC68B8.7148D140--

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".