Some programs (vi, ssh) crash when screen buffer height is big

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Some programs (vi, ssh) crash when screen buffer height is big

sous lesquels
**** Environment

CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46
Windows 7

**** Steps to reproduce the issue:

- With vi.exe

Execute the following bash script:

#!/bin/bash
for i in {1..123}; do
  echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
  head -n1000 /var/log/setup.log
done
vi /var/log/setup.log

vi breaks with something as:

      0 [main] vi 13200 C:\cygwin64\bin\vi.exe: *** fatal error -
cmalloc would have returned NULL
/4.sh: line 6: 13200 Hangup                  vi /var/log/setup.log

(note 4.sh is the file name I used to put the above script in and run
it from there) and leaves a vi.exe.stackdump with the following
contents:

Stack trace:
Frame        Function    Args
001004D2D08  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000229480)
001004D2D08  00180046E32 (0000022A4E8, FF000000808080, FFFF000000FF00,
FF00FF000000FF)
001004D2D08  00180046E72 (001801E8643, 00000000000, 00000000000, 00000000000)
001004D2D08  00180043983 (00076D22F7E, 00000000000, 00000000000, 00000000000)
001004D2D08  0018007B781 (FFFF000000FF00, FF00FF000000FF,
FFFFFF0000FFFF, 00180000088)
001004D2D08  0018007B91F (00000000000, 00000000000, 00000000000, 00000000000)
001004D2D08  0018007E024 (00000000000, 00000000000, 00000000000, 00000000000)
001004D2D00  001801266FD (00000000000, 00000000000, 1A1311121C011615,
001802E2788)
001004D4160  0018011197B (00000000000, 00000000000, 1A1311121C011615,
001802E2788)
End of stack trace

- With ssh.exe

ssh to some machine (Linux in my case) and execute the following bash script:

#!/bin/bash
for i in {1..123}; do
  echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
  head -n1000 /var/log/dmesg
done
vi /var/log/dmesg

ssh breaks with:

0 [main] ssh 12464 C:\cygwin64\bin\ssh.exe: *** fatal error - cmalloc
would have returned NULL

and leaves a ssh.exe.stackdump file in the current working directory
with the following contents:

Stack trace:
Frame        Function    Args
006000A267F  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000226B60)
006000A267F  00180046E32 (00000227BC8, FF000000808080, FFFF000000FF00,
FF00FF000000FF)
006000A267F  00180046E72 (001801E8643, 00000000000, 00000000000, 00100000002)
006000A267F  00180043983 (00076D22F7E, 00000000000, 0018007B522, 0000000270E)
006000A267F  0018007B781 (FFFF000000FF00, FF00FF000000FF,
FFFFFF0000FFFF, 00180000088)
006000A267F  0018007B91F (000000001DC, 00000000000, 00000000000, 00000000000)
006000A267F  0018007E024 (00600077990, 00000000007, 00600077990, 00000000007)
006000A0490  001801266FD (00100426798, 00000000000, 00000000000, 00000000000)
0060006E850  0018011197B (00000000000, 00000000000, 00000000000, 00000000000)
0060006E850  00000004000 (00000000000, 00000000000, 00000000000, 21EF00000000)
0060006E850  00100426798 (00000000000, 001004928A0, 2BE9E0C5343523AB,
00000228090)
0060006E850  00600068670 (001004928A0, 2BE9E0C5343523AB, 00000228090,
00000000000)
0060006E850  003FEF96000 (001004928A0, 2BE9E0C5343523AB, 00000228090,
00000000000)
End of stack trace

**** More information:

- For both variants, you may need to tweak the number 123 in the for
loop above or the location of files if you don't have these - they
should be there, but if not pick any file with some log-like text in
it (a few hundred lines should be enough)

- The variants are just quick and dirty ways to reproduce - crashes
happen in regular work in various situations (i.e. real scenarios, not
contrived as above)

- Crashes can be reproduced always

- Taking the same steps as above when running from Cygwin terminal
(i.e. the one that comes bundled with Cygwin itself) does not result
in a crash

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

sous lesquels
A few more things to add:

- This crashes under the regular Windows console, i.e. run cmd.exe,
then bash, then follow the above
- It also crashes under some other emulators (I actually noticed it
under ConEmu, see
https://code.google.com/p/conemu-maximus5/issues/detail?id=1644),
though this is likely due to the fact the regular Windows console is
used underneath
- When I said "screen buffer size", I mean the option in the Windows
console - right click on the cmd.exe taskbar, Properties, Layout tab,
Screen Buffer Size / Height - I could reproduce with 1000. It does not
seem to be reproducible with low values (e.g. I tried with 100, 200,
500 and it seemed to work - not sure if it would have broken later,
but it's not always reproducible as it is with 1000+)

On Wed, Jul 16, 2014 at 4:10 PM, sous lesquels <[hidden email]> wrote:

> **** Environment
>
> CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46
> Windows 7
>
> **** Steps to reproduce the issue:
>
> - With vi.exe
>
> Execute the following bash script:
>
> #!/bin/bash
> for i in {1..123}; do
>   echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
>   head -n1000 /var/log/setup.log
> done
> vi /var/log/setup.log
>
> vi breaks with something as:
>
>       0 [main] vi 13200 C:\cygwin64\bin\vi.exe: *** fatal error -
> cmalloc would have returned NULL
> /4.sh: line 6: 13200 Hangup                  vi /var/log/setup.log
>
> (note 4.sh is the file name I used to put the above script in and run
> it from there) and leaves a vi.exe.stackdump with the following
> contents:
>
> Stack trace:
> Frame        Function    Args
> 001004D2D08  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000229480)
> 001004D2D08  00180046E32 (0000022A4E8, FF000000808080, FFFF000000FF00,
> FF00FF000000FF)
> 001004D2D08  00180046E72 (001801E8643, 00000000000, 00000000000, 00000000000)
> 001004D2D08  00180043983 (00076D22F7E, 00000000000, 00000000000, 00000000000)
> 001004D2D08  0018007B781 (FFFF000000FF00, FF00FF000000FF,
> FFFFFF0000FFFF, 00180000088)
> 001004D2D08  0018007B91F (00000000000, 00000000000, 00000000000, 00000000000)
> 001004D2D08  0018007E024 (00000000000, 00000000000, 00000000000, 00000000000)
> 001004D2D00  001801266FD (00000000000, 00000000000, 1A1311121C011615,
> 001802E2788)
> 001004D4160  0018011197B (00000000000, 00000000000, 1A1311121C011615,
> 001802E2788)
> End of stack trace
>
> - With ssh.exe
>
> ssh to some machine (Linux in my case) and execute the following bash script:
>
> #!/bin/bash
> for i in {1..123}; do
>   echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
>   head -n1000 /var/log/dmesg
> done
> vi /var/log/dmesg
>
> ssh breaks with:
>
> 0 [main] ssh 12464 C:\cygwin64\bin\ssh.exe: *** fatal error - cmalloc
> would have returned NULL
>
> and leaves a ssh.exe.stackdump file in the current working directory
> with the following contents:
>
> Stack trace:
> Frame        Function    Args
> 006000A267F  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000226B60)
> 006000A267F  00180046E32 (00000227BC8, FF000000808080, FFFF000000FF00,
> FF00FF000000FF)
> 006000A267F  00180046E72 (001801E8643, 00000000000, 00000000000, 00100000002)
> 006000A267F  00180043983 (00076D22F7E, 00000000000, 0018007B522, 0000000270E)
> 006000A267F  0018007B781 (FFFF000000FF00, FF00FF000000FF,
> FFFFFF0000FFFF, 00180000088)
> 006000A267F  0018007B91F (000000001DC, 00000000000, 00000000000, 00000000000)
> 006000A267F  0018007E024 (00600077990, 00000000007, 00600077990, 00000000007)
> 006000A0490  001801266FD (00100426798, 00000000000, 00000000000, 00000000000)
> 0060006E850  0018011197B (00000000000, 00000000000, 00000000000, 00000000000)
> 0060006E850  00000004000 (00000000000, 00000000000, 00000000000, 21EF00000000)
> 0060006E850  00100426798 (00000000000, 001004928A0, 2BE9E0C5343523AB,
> 00000228090)
> 0060006E850  00600068670 (001004928A0, 2BE9E0C5343523AB, 00000228090,
> 00000000000)
> 0060006E850  003FEF96000 (001004928A0, 2BE9E0C5343523AB, 00000228090,
> 00000000000)
> End of stack trace
>
> **** More information:
>
> - For both variants, you may need to tweak the number 123 in the for
> loop above or the location of files if you don't have these - they
> should be there, but if not pick any file with some log-like text in
> it (a few hundred lines should be enough)
>
> - The variants are just quick and dirty ways to reproduce - crashes
> happen in regular work in various situations (i.e. real scenarios, not
> contrived as above)
>
> - Crashes can be reproduced always
>
> - Taking the same steps as above when running from Cygwin terminal
> (i.e. the one that comes bundled with Cygwin itself) does not result
> in a crash

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

Christopher Faylor-8
On Wed, Jul 16, 2014 at 04:29:54PM -0400, sous lesquels wrote:
>A few more things to add:
>
>- This crashes under the regular Windows console, i.e. run cmd.exe,
>then bash, then follow the above

You've discovered that Cygwin has limits.  You can't run it with console
windows that are too big.  Sorry.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

Corinna Vinschen-2
In reply to this post by sous lesquels
On Jul 16 16:29, sous lesquels wrote:

> A few more things to add:
>
> - This crashes under the regular Windows console, i.e. run cmd.exe,
> then bash, then follow the above
> - It also crashes under some other emulators (I actually noticed it
> under ConEmu, see
> https://code.google.com/p/conemu-maximus5/issues/detail?id=1644),
> though this is likely due to the fact the regular Windows console is
> used underneath
> - When I said "screen buffer size", I mean the option in the Windows
> console - right click on the cmd.exe taskbar, Properties, Layout tab,
> Screen Buffer Size / Height - I could reproduce with 1000. It does not
> seem to be reproducible with low values (e.g. I tried with 100, 200,
> 500 and it seemed to work - not sure if it would have broken later,
> but it's not always reproducible as it is with 1000+)
It's not reproducible for me.  I just tried your ssh scenario with a
1000 and 2000 line buffers and it works fine for me every time, be it
with Cygwin 1.7.30 or the latest snapshot.  I also raised the number of
loops.  Is it possible that you're suffering a BLODA(*) problem?


Thanks,
Corinna

(*) https://cygwin.com/faq/faq.html#faq.using.bloda

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

Warren Young
On 7/17/2014 02:24, Corinna Vinschen wrote:
>
> It's not reproducible for me.  I just tried your ssh scenario with a
> 1000 and 2000 line buffers

Confirmed.

I tried up to 9999, the maximum allowed.

This is under Windows 8.1 Pro, with Cygwin 1.7.30, both 32- and 64-bit.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

sous lesquels
In reply to this post by sous lesquels
> It's not reproducible for me.  I just tried your ssh scenario with a
> 1000 and 2000 line buffers and it works fine for me every time, be it
> with Cygwin 1.7.30 or the latest snapshot.  I also raised the number of
> loops.  Is it possible that you're suffering a BLODA(*) problem?
>
>
> Thanks,
> Corinna

> Confirmed.
>
> I tried up to 9999, the maximum allowed.
>
> This is under Windows 8.1 Pro, with Cygwin 1.7.30, both 32- and 64-bit.

I was running under:

CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46

It might have been a feature present in 1.7.29.

More likely, it was a installation issue. I had cygwin1.dll with
1.7.29 and cygwin1.dll.new with 1.7.30. I ran setup-x86_64.exe
multiple times and it did nothing to upgrade it (I assume it renames
cygwin1.dll.new to cygwin1.dll, correct?). No cywgin processes were
running otherwise. What helped is to manually reinstall "cygwin"
package. Now that I'm at 1.7.30, all seems OK. Probably just a version
mismatch.

As a side topic, I did not get a mail with your (Corinna / Warren)
replies, just a digest, and could not reply to it. Not sure how it
will thread. Is there a way to somehow specify which post to reply to
in the body of the mail, so that it threads as I want? As per
https://sourceware.org/lists.html#what-software, ezmlm-idx is used and
as per http://untroubled.org/ezmlm/faq/How-threading-works.html#How-threading-works
it threads by subject, not using In-Reply-To or so. And even if it
did, I cannot specify headers via Gmail (firewall, cannot use other
email clients unfortunately). If not a simple answer, I'll open a
separate thread.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

Larry Hall (Cygwin)
On 07/18/2014 10:48 AM, sous lesquels wrote:

>> It's not reproducible for me.  I just tried your ssh scenario with a
>> 1000 and 2000 line buffers and it works fine for me every time, be it
>> with Cygwin 1.7.30 or the latest snapshot.  I also raised the number of
>> loops.  Is it possible that you're suffering a BLODA(*) problem?
>>
>>
>> Thanks,
>> Corinna
>
>> Confirmed.
>>
>> I tried up to 9999, the maximum allowed.
>>
>> This is under Windows 8.1 Pro, with Cygwin 1.7.30, both 32- and 64-bit.
>
> I was running under:
>
> CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46
>
> It might have been a feature present in 1.7.29.
>
> More likely, it was a installation issue. I had cygwin1.dll with
> 1.7.29 and cygwin1.dll.new with 1.7.30. I ran setup-x86_64.exe
> multiple times and it did nothing to upgrade it (I assume it renames
> cygwin1.dll.new to cygwin1.dll, correct?). No cywgin processes were
> running otherwise. What helped is to manually reinstall "cygwin"
> package. Now that I'm at 1.7.30, all seems OK. Probably just a version
> mismatch.

This is not the recommended way of handling this situation.  You end up
with a ".new" extension if the DLL was in use at the time of your upgrade.
In this case, setup*.exe schedules a replace of your existing DLL with the
".new" version on reboot.  So if you find such a file on your system, the
sanctioned resolution to this is to reboot.

> As a side topic, I did not get a mail with your (Corinna / Warren)
> replies, just a digest, and could not reply to it. Not sure how it
> will thread. Is there a way to somehow specify which post to reply to
> in the body of the mail, so that it threads as I want? As per
> https://sourceware.org/lists.html#what-software, ezmlm-idx is used and
> as per http://untroubled.org/ezmlm/faq/How-threading-works.html#How-threading-works
> it threads by subject, not using In-Reply-To or so. And even if it
> did, I cannot specify headers via Gmail (firewall, cannot use other
> email clients unfortunately). If not a simple answer, I'll open a
> separate thread.

You must have subscribed to the list and requested a digest.  By
default, any email replies to this list go to the list.  If you
want a direct copy, you have to ask for it and you rely on the
kindness of the responder to put in the extra effort to comply.
The best way to get individual messages from this list that are easy
to reply to is to subscribe without using the digest option.


--
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

sous lesquels
Thanks Larry.

> This is not the recommended way of handling this situation.  You end up
> with a ".new" extension if the DLL was in use at the time of your upgrade.
> In this case, setup*.exe schedules a replace of your existing DLL with the
> ".new" version on reboot.  So if you find such a file on your system, the
> sanctioned resolution to this is to reboot.

OK, thanks for clarifying the update process. I thought maybe setup
when started will try to update a file anyway (if not in use at that
time, even though it was in use before).

Note that I did not know there was "a situation" in the first place :)
I definitively rebooted multiple times in between and it looks like it
did not get replaced - maybe an issue with scheduling a replace?

> You must have subscribed to the list and requested a digest.
That I was.

> By default, any email replies to this list go to the list.
Makes sense, however it would not go to this thread, probably just
create a new thread, correct?

> The best way to get individual messages from this list that are easy
> to reply to is to subscribe without using the digest option
Agree, had I been subscribed, I would have gotten the message to reply
to, but I unfortunately was only getting digests.

Just to note - I'm not asking for the poster to reply to me, just
wondering if it's possible to somehow send a mail and tell the mailing
list software to thread beneath a specific node of the thread index.
E.g. put In-Repy-To: <msg ID> (which I can get from the raw text of
the post) in the body or something like that that I'm not aware of?

If not, there's no way to thread properly in various cases such as:

- I've posted something a month ago and don't want to be spammed by
unrelated posts (which would be hundreds in that time span), then a
reply comes
- I've accidentally deleted the mail
- I want to respond to a post that was posted before I subscribed

Any suggestions? Or is this not as common use case as I think it is?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

Christopher Faylor-8
On Fri, Jul 18, 2014 at 12:59:10PM -0400, sous lesquels wrote:
>Any suggestions? Or is this not as common use case as I think it is?

Craft your reply with the appropriate "In-Reply-To" header tag and it
will maintain threading.

There is no automated way to do that if you are using the digest.  Digests
are intended for casual perusal of the list, not for active communication.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

RE: Some programs (vi, ssh) crash when screen buffer height is big

Nellis, Kenneth-3
> From: Christopher Faylor
> There is no automated way to do that if you are using the digest.  Digests
> are intended for casual perusal of the list, not for active communication.

FWIW, I get digest format, but still make threaded replies (such as this) with
a few extra steps that may not be obvious. This presumes using Outlook. YMMV.

If you can wait for the digest, you can simply open the selected message from
the digest and reply to that, and it will be threaded.

If you can't wait, then read the message using your browser and click on the
"Raw text" link near the top. The first line will say something like
From cygwin-return-191383-listarch-cygwin=...
Note the message number 191383.
Then you send an empty message to [hidden email] and it will
mail you back the specified message. You can then reply to it and your reply
will be threaded.

--Ken Nellis


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

sous lesquels
> If you can wait for the digest, you can simply open the selected message from
> the digest and reply to that, and it will be threaded.
Using Gmail, it doesn't seem to offer a way to see them as separate
mails or reply to a particular one, though. Oh, well...

> If you can't wait, then read the message using your browser and click on the
> "Raw text" link near the top. The first line will say something like
> From cygwin-return-191383-listarch-cygwin=...
> Note the message number 191383.
> Then you send an empty message to [hidden email] and it will
> mail you back the specified message. You can then reply to it and your reply
> will be threaded.
Perfect, exactly what I was looking for. Agree it's not the most
direct method, but then again solves all the situations I could think
of requiring a physical email message that can be replied to.

Thanks for the tip Ken!

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

RE: Some programs (vi, ssh) crash when screen buffer height is big

Nellis, Kenneth-3
> From: sous lesquels
> <snip>
> > If you can't wait, then read the message using your browser and click
> > on the "Raw text" link near the top. The first line will say something
> > like From cygwin-return-191383-listarch-cygwin=...
> > Note the message number 191383.
> > Then you send an empty message to [hidden email] and it
> > will mail you back the specified message. You can then reply to it and
> > your reply will be threaded.
> Perfect, exactly what I was looking for. Agree it's not the most direct
> method, but then again solves all the situations I could think of
> requiring a physical email message that can be replied to.
>
> Thanks for the tip Ken!

Glad to help.
I'm thinking it should be dirt simple for the web site maintainer
to add a hyperlink right on the message web page, perhaps under the
"Raw text" link, which would say something like "Request this message".
It would simply be a mailto: link with the correct message number added.
I'm thinking this could make life much easier for digest readers,
like myself. In the example above, the link would be:
<a href="mailto:[hidden email]">Request this message</a>
The only trick would be inserting the proper message number.

--Ken Nellis
Reply | Threaded
Open this post in threaded view
|

Re: Some programs (vi, ssh) crash when screen buffer height is big

Christopher Faylor-8
On Mon, Jul 21, 2014 at 12:32:34PM +0000, Nellis, Kenneth wrote:

>> From: sous lesquels
>> <snip>
>> > If you can't wait, then read the message using your browser and click
>> > on the "Raw text" link near the top. The first line will say something
>> > like From cygwin-return-191383-listarch-cygwin=...
>> > Note the message number 191383.
>> > Then you send an empty message to [hidden email] and it
>> > will mail you back the specified message. You can then reply to it and
>> > your reply will be threaded.
>> Perfect, exactly what I was looking for. Agree it's not the most direct
>> method, but then again solves all the situations I could think of
>> requiring a physical email message that can be replied to.
>>
>> Thanks for the tip Ken!
>
>Glad to help.
>I'm thinking it should be dirt simple for the web site maintainer
>to add a hyperlink right on the message web page, perhaps under the
>"Raw text" link, which would say something like "Request this message".
>It would simply be a mailto: link with the correct message number added.
>I'm thinking this could make life much easier for digest readers,
>like myself. In the example above, the link would be:
><a href="mailto:[hidden email]">Request this message</a>
>The only trick would be inserting the proper message number.

No, we're not going to change the way the web archive works.  There is
no easy way that the archiving software would know what the mailto: link
would be.  And, I'm not too interested in hacking at the archiver
anyway.

I'll say it again: Just add the In-Reply-To or References with the right
Message-ID and you'll get threading.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple