Re: headache on build repeatibility: octave vs BLODA ?
Am 27.01.2020 um 12:33 schrieb Takashi Yano: On Mon, 27 Jan 2020 07:45:08 +0100 Marco Atzeri wrote: Can you and Takashi provide me your cygcheck.out so that I can look on possible difference that could influence the build behaviour. Attached. Thanks Takashi, I duplicated your installation from scratch on my W10 Home and it fails again in the same place. So I am now almost sure that the recent MS updates changed/broke something in W10 Home. :-(( Assuming it does not break German systems and left immune Japanese ones :-? I will try to install the same in a W10 Pro and if that does not segfault I can try the lengthy process to compare the object/dll/exec files to see where is the difference. Corinna, there are specific code differences in Cygwin DLL between W10 Home and Pro ? Regards Marco -- 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
Re: grace broken installation
On 2020-01-27 16:24, Hans-Bernhard Bröker wrote:
> Am 27.01.2020 um 13:58 schrieb Ken Brown:
>> On 1/26/2020 10:25 PM, Hans-Bernhard Bröker wrote:
>>> Am 25.01.2020 um 15:23 schrieb Rodrigo Medina:
Hi,
Both installations of grace-5.1.24 and grace-5.1.245 are broken.
/usr/bin/xmgrace.exe runs but gives the message:
--> Broken or incomplete installation - read the FAQ!
and then quits.
>
>>> After reading the FAQ and comparing with a direct build from upstream
>>> sources, I
>>> find the reason for that is that the FontDataBase file of the distributed
>>> package is, indeed, wrong.
>
>>> Apparently the type1 font directory supplied by grace was replaced by a
>>> link to
>>> ghostscript's type1 font repository. But the FontDataBase wasn't updated to
>>> match this change. This mismatch causes xmgrace to baulk. This change was
>>> made
>>> between revisions 5.1.24 and 5.1.25 of the cygwin package, which neatly
>>> explains
>>> why 5.1.24 works, but 5.1.25 does not.
>>
>> See
>>
>> https://cygwin.com/ml/cygwin/2018-03/msg00142.html
>> https://cygwin.com/ml/cygwin/2018-03/msg00156.html
>
> Yes, that's about what I figured. The fonts supplied by xmgrace were replaced
> (in the cygport file) by a link to ghostscript's fonts, but then those were
> replaced by URW fonts, which broke xmgrace.
>
> OTOH the particular font files xmgrace is looking for are in yet another place
> on Cygwin:
>
> /usr/share/X11/fonts/urw-fonts
>
> And indeed, making the /usr/share/grace/fonts/type1 symlink point there
> does appear to fix the breakage.
>
> So the minimal patch to grace.cygport (other than just leaving the type1
> directory of xmgrace alone) would be:
>
> $ diff -uwp grace.cygport{~,}
> --- grace.cygport~ 2017-06-27 09:43:32.0 +0200
> +++ grace.cygport 2020-01-28 00:08:56.345429500 +0100
> @@ -78,7 +78,7 @@ src_install() {
> rmdir doc
> ln -sf ../doc/${NAME} doc
> rm -fr fonts/type1
> - ln -sf /usr/share/ghostscript/fonts fonts/type1
> + ln -sf /usr/share/X11/fonts/urw-fonts fonts/type1
> popd
>
> make_desktop_entry xmgrace Grace xmgrace
> "Education;Science;DataVisualization;Motif"
>
> An additional/changed dependency on the urw-base35-fonts-legacy package would
> probably be needed, but I'll have to leave that to people who understand
> Cygwin
> packaging.
Links should only be applied during build processes to allow building and
testing to complete successfully.
Build link types may not be compatible with tar or the target file system and
should not be included in packages for distribution e.g. they may only work on
systems configured for WSL and with WSL installed.
Distributed package links should be generated during post-install processing and
should fall back to file copies if links are unsupported on the target file
system.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
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
Family holiday
Dear Manager, My name is Marshall M. Tolliver i will like to make a booking for my family upcoming visit to your country we will be coming from the united Kingdom arriving on the 16th of February and depart on the 25th of February 2020, we kindly requested for 10 night booking, 2 double rooms or equivalent for these period. Please let me know if you have these night available at your place, also i will like to know if you hotel accept payment in advance. do send me your terms and condition of booking and cancellation. Thanks and best regards. Marshall M. Tolliver -- 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
Re: grace broken installation
Am 27.01.2020 um 13:58 schrieb Ken Brown:
On 1/26/2020 10:25 PM, Hans-Bernhard Bröker wrote:
Am 25.01.2020 um 15:23 schrieb Rodrigo Medina:
Hi,
Both installations of grace-5.1.24 and grace-5.1.245 are broken.
/usr/bin/xmgrace.exe runs but gives the message:
--> Broken or incomplete installation - read the FAQ!
and then quits.
After reading the FAQ and comparing with a direct build from upstream sources, I
find the reason for that is that the FontDataBase file of the distributed
package is, indeed, wrong.
Apparently the type1 font directory supplied by grace was replaced by a link to
ghostscript's type1 font repository. But the FontDataBase wasn't updated to
match this change. This mismatch causes xmgrace to baulk. This change was made
between revisions 5.1.24 and 5.1.25 of the cygwin package, which neatly explains
why 5.1.24 works, but 5.1.25 does not.
See
https://cygwin.com/ml/cygwin/2018-03/msg00142.html
https://cygwin.com/ml/cygwin/2018-03/msg00156.html
Yes, that's about what I figured. The fonts supplied by xmgrace were
replaced (in the cygport file) by a link to ghostscript's fonts, but
then those were replaced by URW fonts, which broke xmgrace.
OTOH the particular font files xmgrace is looking for are in yet another
place on Cygwin:
/usr/share/X11/fonts/urw-fonts
And indeed, making the /usr/share/grace/fonts/type1 symlink point there
does appear to fix the breakage.
So the minimal patch to grace.cygport (other than just leaving the type1
directory of xmgrace alone) would be:
$ diff -uwp grace.cygport{~,}
--- grace.cygport~ 2017-06-27 09:43:32.0 +0200
+++ grace.cygport 2020-01-28 00:08:56.345429500 +0100
@@ -78,7 +78,7 @@ src_install() {
rmdir doc
ln -sf ../doc/${NAME} doc
rm -fr fonts/type1
- ln -sf /usr/share/ghostscript/fonts fonts/type1
+ ln -sf /usr/share/X11/fonts/urw-fonts fonts/type1
popd
make_desktop_entry xmgrace Grace xmgrace
"Education;Science;DataVisualization;Motif"
An additional/changed dependency on the urw-base35-fonts-legacy package
would probably be needed, but I'll have to leave that to people who
understand Cygwin packaging.
--
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
Re: Windows Restart Manager and cygrunsrv services
On Mon, Jan 27, 2020 at 9:19 AM Bill Stewart wrote: > > Any ideas why Restart Manager doesn't work for cygrunsrv services? > ... > Question also posted on StackOverflow: > > https://stackoverflow.com/questions/59902201/ > > Any insights appreciated. According to my investigation and understanding as of this writing, the behavior appears to be as follows: 1. Restart Manager sees the cygrunsrv.exe executable correctly as a service and as restartable. This is good. 2. However, any executable spawned by cygrunsrv.exe as a service (e.g., sshd.exe), is seen as NOT restartable for some reason. This is not so good, and prevents the service from being restarted automatically by Restart Manager. I don't know the explanation for this behavior. It seems unintuitive and is confusing, at the least. Just a guess: Perhaps this behavior would be resolved if Cygwin executables used RegisterApplicationRestart[1] ? In any case, I have an imperfect workaround, but it would be good if this workaround wasn't necessary. Regards, Bill __ [1] https://docs.microsoft.com/en-us/windows/win32/recovery/registering-for-application-restart -- 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
Re: openmpi warning "unable to open debugger attach fifo"
Am 27.01.2020 um 22:28 schrieb Ken Brown: On 1/27/2020 1:49 PM, Ken Brown wrote: On 1/27/2020 11:41 AM, Satish Balay wrote: Hi, On using openmpi from cygwin - I'm getting the following warning. Any idea how to avoid this? balay@ps5 ~ $ /usr/bin/mpiexec -n 1 hostname ps5 [ps5:00491] [[23611,0],0] unable to open debugger attach fifo The attempt to open a FIFO in the source file orte/orted/orted_submit.c:2862 is failing due to a Cygwin bug. I think I see how to fix it. Stay tuned. Sorry, I spoke too soon and was misinterpreting some code I was reading. I don't see a Cygwin bug after all. Moreover, if I run your command under gdb, I don't get an error. Ken I will look if the release candidate for 3.1.6 has still that issue. 3.1.5 had another larger warning that I silenced and that was due to an upstream bug that has been solved. This warning passed below my radar after I solved the bigger one. Unfortunately OpenMPI takes age to build so do not expect any too early.. Regards Marco -- 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
Re: openmpi warning "unable to open debugger attach fifo"
On 1/27/2020 1:49 PM, Ken Brown wrote: > On 1/27/2020 11:41 AM, Satish Balay wrote: >> Hi, >> >> On using openmpi from cygwin - I'm getting the following warning. Any idea >> how to avoid this? >> >> balay@ps5 ~ >> $ /usr/bin/mpiexec -n 1 hostname >> ps5 >> [ps5:00491] [[23611,0],0] unable to open debugger attach fifo > > The attempt to open a FIFO in the source file orte/orted/orted_submit.c:2862 > is > failing due to a Cygwin bug. I think I see how to fix it. Stay tuned. Sorry, I spoke too soon and was misinterpreting some code I was reading. I don't see a Cygwin bug after all. Moreover, if I run your command under gdb, I don't get an error. 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
Re: anyone interested in loading a portable drive?
On 2020-01-27 09:17, Bill Stewart wrote: > On Sun, Jan 26, 2020 at 9:33 PM aimedtech wrote: > >> Okay, this is a complaint. I've spent the past few days trying to >> download the Cygwin system and gotten nowhere. I've tried several >> download environments, using different protocols, nothing works. > > Remember that we can't see your screen. > > When you say that something didn't work, you have to say how it didn't > work. https://devblogs.microsoft.com/oldnewthing/20100421-00/?p=14283 > > First, try reading the error message. > https://devblogs.microsoft.com/oldnewthing/20090625-00/?p=17753 You said your install is a decade old: rename any old /etc/passwd or /etc/group files as those could cause problems nowadays if not regenerated, and you no longer really need them, and should consult the User Guide for those uses. Don't use user names, home, root, or package directory names with spaces, or C:\ as root directory: you should have full control over those directories, and run setup with an admin id so it can run elevated. Select only the packages you need to install, as all packages take 148GB, which will take a while to download, as long to install, and a lot of virtual memory to run (assuming you're installing a 64 bit system, and have a lot of paging space; if not, it won't install and won't run, as installing a lot of packages using a lot of DLLs may require more than 3-4GB address space). You should stop and exit all Cygwin processes so none are running while you run setup. See https://cygwin.com/faq/faq.html#faq.setup.setup-fails Most problems with setup are network problems: in case it's not network, attach setup.log.full (possibly in /var/log/ or the directory from which you ran setup) as a plain text attachment for diagnosis. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
Re: openmpi warning "unable to open debugger attach fifo"
On 1/27/2020 11:41 AM, Satish Balay wrote: > Hi, > > On using openmpi from cygwin - I'm getting the following warning. Any idea > how to avoid this? > >>> > balay@ps5 ~ > $ /usr/bin/mpiexec -n 1 hostname > ps5 > [ps5:00491] [[23611,0],0] unable to open debugger attach fifo The attempt to open a FIFO in the source file orte/orted/orted_submit.c:2862 is failing due to a Cygwin bug. I think I see how to fix it. Stay tuned. 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
Re: configured FZF call fails since update from Cygwin 3.0.7 to 3.1.2
Hi Marco, On Wed, 22 Jan 2020 at 08:56, Trosi, Marco wrote: > > Hi Marco, > > > > On Fri, 17 Jan 2020 at 09:43, Trosi, Marco wrote: > > > > > > Hello everyone and a happy new year, > > > > > > I updated recently Cygwin from 3.0.7 to 3.1.2, and now when I run "fzf" > > > the following happens. > > > > > > > > > > While I'm nominally the Cygwin maintainer for fzf, the upstream > > source has stopped supporting the version Cygwin uses, which means > > there's incredibly little help I can offer. > > > > I vaguely intended to create a supported fork of the Ruby fzf > > version that Cygwin runs, but never managed to make any useful > > progress on it. At this point, it's unlikely I'm ever going to, > > either. > > > > If you're interested in taking over the maintainership and working > > out your problems yourself, that's something I'm definitely willing > > to help with insofar as I can, but otherwise I'm afraid you're on > > your own here. > > > > (For context: the version of fzf that Cygwin uses is written in > > Ruby, but some time ago the upstream fzf project switched from a > > Ruby-based version to a Go-based version. Cygwin doesn't have a > > native Go compiler, and getting a working Cygwin-packaged version of > > fzf using a non-Cygwin Go compiler was beyond what I could achieve > > with the time available to me.) > > > > Adam > > Hi, > > Thanks for the offer. > > Do you really think it has something to do with FZF? > FZF is working perfectly. > The issue occurs only when I use my "fdc" wrapper script and since update to > Cygwin 3.1.2. > Currently it feels to me like some kind of Cygwin internal string/pipe/stream > handling thing. > Okay maybe Cygwin changed something on purpose and FZF needs to be updated > accordingly, is that what you think is happening here? I think it's unlikely that the problem is with FZF, however given that's where you're spotting the problem, someone needs to narrow down what's going on, and that'll require either digging into what FZF is doing, or otherwise coming up with a simple test case that doesn't involve FZF. As is more-or-less always the case with open source projects, someone has to do that work. That might be me, as FZF maintainer, but as above, I simply don't have the bandwidth to do that. It could be someone else involved in the Cygwin project, but given nobody else has replied to this thread on the Cygwin mailing list, I don't think you're likely to have much luck waiting on that. Which, I'm afraid, leaves you. If you can get a simple test case that shows the problem and doesn't involve FZF, I expect other people on the list will be much better placed to help. Until and unless that simple test case exists, however, I think there's unlikely to be any more progress unless someone else happens to discover the same problems by chance. Adam PS: Convention on this list, per the links in the email footer, is to reply to the list, not to individuals, as it means everyone on the list can help rather than requiring one person to do all the labour. We also prefer to reply in-line below the text (as I'm doing here) and to not quote raw email addresses, since otherwise they get harvested by spammers from the email archives. -- 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
RE: cin and read(*,*) not waiting for kbd input in gdb
[snip]
>>>I'm not able to reproduce this problem. Perhaps you can provide a similar
>>>transcript showing the steps to reproduce?
[snip]
>>Test code:
> >program test
>>implicit none
>> realcycle_time_preset /0.0/ ! (seconds)
>> realcycle_length /0.0/ ! (seconds)
>> do
>> if (cycle_time_preset.le.0.0) then
>> write(*,*)'Supply the equivalent of run time in seconds.'
>>write(*,"('(Note: a negative run time will stop run): ',$)")
>> read(*,*) cycle_length
>>else
>> cycle_length = cycle_time_preset
>>end if
>>if (cycle_length .lt. 0.0) stop 'normal termination'
>>end do
>>stop
>>end
>>$ /usr/bin/gfortran -g -ffree-form -ffree-line-length-none -Wunused
>>-ffpe-trap=invalid,zero,overflow -o test.exe test.f
[snip]
>Following your test I do not have cin wait for kbd input whenever a breakpoint
>is set.
>In fact, if I run 'disa 1' to disable the breakpoint and then just 'run'
>(to restart the program from the beginning) then the program does pause for my
>keyboard input.
>This happens in both my Win 7 and Win 7 - RTX OS boots.
>This happens in both gdb 8.2.1-1 and 8.3.1-1. It does not happen with Gdb
>version 8.1.1-1.
[snip]
I don't know if this is a gdb or a Cygwin implementation of gdb that is a
problem.
Since I can go back to gdb version 8.1.1-1 this is not a problem for me now.
Here is a test case using the Fortran source above:
$ gfortran -g test1.f -o test1.exe
harryr@HARRYR-PC ~/d62sim/Excel
$ gdb test1
GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
openmpi warning "unable to open debugger attach fifo"
Hi, On using openmpi from cygwin - I'm getting the following warning. Any idea how to avoid this? >> balay@ps5 ~ $ /usr/bin/mpiexec -n 1 hostname ps5 [ps5:00491] [[23611,0],0] unable to open debugger attach fifo balay@ps5 ~ $ cygcheck.exe -cd cygwin openmpi Cygwin Package Information Package Version cygwin 3.1.2-1 openmpi 3.1.2-2 balay@ps5 ~ $ < PS: Appreciate if you can cc me on replies. Thanks, Satish -- 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
Re: Windows Restart Manager and cygrunsrv services
On Thu, Jan 23, 2020 at 10:44 AM Bill Stewart wrote: > However it seems that when running a service using cygrunsrv, the > Restart Manager RmGetList API[2] returns RmRebootReasonSessionMismatch > (2) for the lpdwRebootReasons output parameter. > > This parameter return value is one of the RM_REBOOT_REASON enumeration > values[3]. > > The description for the RmRebootReasonSessionMismatch value on MSDN is > as follows: "One or more processes are running in another Terminal > Services session." > > I ran into this building an Inno Setup installer. I reproduced on > Windows 10 x64 and Windows Server 2008 R2 x64. > > The error description is interesting, because in neither repro case > were there other users logged on using TS sessions. (I'm not sure if > that error description is completely accurate in describing all cases > where that value gets returned, though...) > > Unexpected behavior: Restart Manager returns 2 > (RmRebootReasonSessionMismatch) in the lpdwRebootReasons output > parameter when calling the RmGetList API to detect a cygrunsrv > service. > > Expected behavior: Restart Manager should return 0 > (RmRebootReasonNone) in the lpdwRebootReasons output parameter when > calling the RmGetList API to detect a cygrunsrv service. > > Further details (regarding Inno Setup and this problem): > https://groups.google.com/d/msg/innosetup/9dAT3wB9RTQ/99Py-ZgLCgAJ > > Any ideas why Restart Manager doesn't work for cygrunsrv services? > > Thanks! > > Bill > > > > [1] > https://docs.microsoft.com/en-us/windows/win32/rstmgr/about-restart-manager > > [2] > https://docs.microsoft.com/en-us/windows/win32/api/restartmanager/nf-restartmanager-rmgetlist > > [3] > https://docs.microsoft.com/en-us/windows/win32/api/restartmanager/ne-restartmanager-rm_reboot_reason Question also posted on StackOverflow: https://stackoverflow.com/questions/59902201/ Any insights appreciated. Thanks! Bill -- 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
Re: anyone interested in loading a portable drive?
On Sun, Jan 26, 2020 at 9:33 PM aimedtech wrote: > Okay, this is a complaint. I've spent the past few days trying to download > the Cygwin system and gotten nowhere. I've tried several download > environments, using different protocols, nothing works. Remember that we can't see your screen. When you say that something didn't work, you have to say how it didn't work. https://devblogs.microsoft.com/oldnewthing/20100421-00/?p=14283 First, try reading the error message. https://devblogs.microsoft.com/oldnewthing/20090625-00/?p=17753 Bill -- 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
Re: anyone interested in loading a portable drive?
On 2020-01-26 23:45, john doe wrote:
> On 1/27/2020 7:38 AM, Brian Inglis wrote:
>> On 2020-01-26 21:33, aimedtech wrote:
>>> Okay, this is a complaint. I've spent the past few days trying to download
>>> the Cygwin system and gotten nowhere. I've tried several download
>>> environments, using different protocols, nothing works.
>>>
>>> And this is beyond being a pain, this is getting to be a real problem for
>>> me. No, that's not right -- it is a problem for me, NOW.
>>>
>>> I remember, I downloaded, installed it and used it, this was about a decade
>>> ago. Then, the area for naming the machine download sites would fill in
>>> automatically; Today, no. I chose a couple and tried them, one at a time.
>>> Neither worked
>>>
>>> I'm not sure if this message is to just tell you that your install is very
>>> broken and goodbye or if I'm asking for help.
>>>
>>> I am willing to send someone a USB 1TB drive and pay $50 bucks to load it
>>> and send it back. If that's what I do I want everything. The works.
>> This is an all-volunteer project and mirrors are donated by the server
>> owners.
>>
>> Weekends are busy times for backups and security upgrades on publicly
>> accessible
>> free servers, and if there are problems, support may not be available until
>> the
>> next work day, after serious production issues are dealt with.
>>
>> Similarly for answers and support from here.
>>
>> The world has changed and Cygwin has become larger in the last decade (148GB
>> according to the Mirrors page).
>>
>> You *MUST* download the latest x86/_64 installer from the home page
>> setup-x86/_64.exe links to get the latest active mirrors and use the current
>> key:
>>
>> https://cygwin.com/setup-x86_64.exe
>> https://cygwin.com/setup-x86.exe
>>
>> Selection from the latest active mirrors to use is easiest by browsing the
>> linked Mirror Sites page:
>>
>> https://cygwin.com/mirrors.html
>>
>> and you should see if you can recognize nearby sites which are likely to have
>> big servers and fast pipes.
>>
>> You may find your closest site(s) overloaded, slow, and connectivity
>> intermittent, depending on the site ownership, day of week, time of day,
>> network
>> path to you, other users on the site and on your local ISP feeds.
>>
>> Avoid evenings and weekends, when many others nearby are downloading the
>> newest
>> Amazon Prime, Apple+. Disney+, Netflix, etc. series to binge watch, and your
>> ISP
>> is also throttling retail customers, to free up bandwidth for their business
>> customers doing offsite streaming backups.
>>
>> Searching for an unofficial mirror at a nearby local university or (Unix)
>> User
>> Group publicly available on the internet may give you better results.
>>
>> Sometimes the closest mirrors may not be the fastest or most reliable, and
>> ftp
>> sites nowadays are slower, less available and reliable than http/https
>> sites, as
>> web sites get the big bucks, servers, memory, and pipes, but ftp sites may be
>> kept around only as long as nothing goes wrong with their old server.
>>
>> Ping, traceroute, simple adhoc bandwidth and throughput tests will give you
>> an
>> idea of the best performance, and experience will tell you about reliability.
>>
>> Start by downloading only the base packges or upgrading what you have
>> installed,
>> and be patient during postinstall steps, as rebasing all the DLLs, and
>> rebuilding updated pages in the man DB, can take a while with large upgrades
>> or
>> outdated installs.
>>
>
> If you are planning to install Cygwin on many hosts, using apt-cacher-ng
> or alike might be of interest to you.
That package is a proxy which is limited, and problematic in many environments
where it might be of use.
Cygwin packages are available for httpd and nginx proxies.
As cygwin setup-x86{,_64} already maintains a cache under
*-l*, *--local-package-dir* /DIR/ Local package directory
syncing updates to that around would suffice.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
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
[PATCH 2/3] Cygwin: fhandler_disk_file::fstatvfs: refactor
Define a new method fhandler_base::fstatvfs_by_handle, extracted from
fhandler_disk_file::fstatvfs, which gets the statvfs information when
a handle is available.
This will be used in future commits for special files that have been
opened with O_PATH.
---
winsup/cygwin/fhandler.h| 1 +
winsup/cygwin/fhandler_disk_file.cc | 22 --
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index c0d56b4da..5fa720a83 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -381,6 +381,7 @@ private:
int __reg2 fstat_by_name (struct stat *buf);
public:
virtual int __reg2 fstatvfs (struct statvfs *buf);
+ int __reg2 fstatvfs_by_handle (HANDLE h, struct statvfs *buf);
int __reg2 utimens_fs (const struct timespec *);
virtual int __reg1 fchmod (mode_t mode);
virtual int __reg2 fchown (uid_t uid, gid_t gid);
diff --git a/winsup/cygwin/fhandler_disk_file.cc
b/winsup/cygwin/fhandler_disk_file.cc
index a1ab2bbdd..89e651029 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -600,9 +600,7 @@ int __reg2
fhandler_disk_file::fstatvfs (struct statvfs *sfs)
{
int ret = -1, opened = 0;
- NTSTATUS status;
IO_STATUS_BLOCK io;
- FILE_FS_FULL_SIZE_INFORMATION full_fsi;
/* We must not use the stat handle here, even if it exists. The handle
has been opened with FILE_OPEN_REPARSE_POINT, thus, in case of a volume
mount point, it points to the FS of the mount point, rather than to the
@@ -630,6 +628,22 @@ fhandler_disk_file::fstatvfs (struct statvfs *sfs)
}
}
+ ret = fstatvfs_by_handle (fh, sfs);
+out:
+ if (opened)
+NtClose (fh);
+ syscall_printf ("%d = fstatvfs(%s, %p)", ret, get_name (), sfs);
+ return ret;
+}
+
+int __reg2
+fhandler_base::fstatvfs_by_handle (HANDLE fh, struct statvfs *sfs)
+{
+ int ret = -1;
+ NTSTATUS status;
+ IO_STATUS_BLOCK io;
+ FILE_FS_FULL_SIZE_INFORMATION full_fsi;
+
sfs->f_files = ULONG_MAX;
sfs->f_ffree = ULONG_MAX;
sfs->f_favail = ULONG_MAX;
@@ -688,10 +702,6 @@ fhandler_disk_file::fstatvfs (struct statvfs *sfs)
debug_printf ("%y = NtQueryVolumeInformationFile"
"(%S, FileFsFullSizeInformation)",
status, pc.get_nt_native_path ());
-out:
- if (opened)
-NtClose (fh);
- syscall_printf ("%d = fstatvfs(%s, %p)", ret, get_name (), sfs);
return ret;
}
--
2.21.0
[PATCH 1/3] Cygwin: fhandler_base::fstat_fs: accomodate the O_PATH flag
Treat a special file opened with O_PATH the same as a regular file,
i.e., use its handle to get the stat information.
Before this change, fstat_fs opened the file a second time, with the
wrong flags and without closing the existing handle. A side effect
was to change the openflags of the file, possibly causing further
system calls to fail.
Currently this change only affects FIFOs, but it will affect
AF_LOCAL/AF_UNIX sockets too once they support O_PATH.
---
winsup/cygwin/fhandler_disk_file.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_disk_file.cc
b/winsup/cygwin/fhandler_disk_file.cc
index 32381a0b0..a1ab2bbdd 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -359,7 +359,7 @@ fhandler_base::fstat_fs (struct stat *buf)
if (get_stat_handle ())
{
- if (!nohandle () && !is_fs_special ())
+ if (!nohandle () && (!is_fs_special () || get_flags () & O_PATH))
res = pc.fs_is_nfs () ? fstat_by_nfs_ea (buf) : fstat_by_handle (buf);
if (res)
res = fstat_by_name (buf);
--
2.21.0
[PATCH 3/3] Cygwin: FIFO::fstatvfs: use our handle if O_PATH is set
If O_PATH is set, then the fhandler_fifo object has a handle that can
be used for getting the statvfs information. Use it by calling
fhandler_base::fstatvfs_by_handle. Before this change,
fhandler_disk_file::fstatfvs was called on a new fhandler_disk object,
which would then have to be opened.
---
winsup/cygwin/fhandler_fifo.cc | 8
1 file changed, 8 insertions(+)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index a338f12cc..ef568f6fe 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -906,6 +906,14 @@ errout:
int __reg2
fhandler_fifo::fstatvfs (struct statvfs *sfs)
{
+ if (get_flags () & O_PATH)
+/* We already have a handle. */
+{
+ HANDLE h = get_handle ();
+ if (h)
+ return fstatvfs_by_handle (h, sfs);
+}
+
fhandler_disk_file fh (pc);
fh.get_device () = FH_FS;
return fh.fstatvfs (sfs);
--
2.21.0
[PATCH 0/3] Some O_PATH fixes
Ken Brown (3): Cygwin: fhandler_base::fstat_fs: accomodate the O_PATH flag Cygwin: fhandler_disk_file::fstatvfs: refactor Cygwin: FIFO::fstatvfs: use our handle if O_PATH is set winsup/cygwin/fhandler.h| 1 + winsup/cygwin/fhandler_disk_file.cc | 24 +--- winsup/cygwin/fhandler_fifo.cc | 8 3 files changed, 26 insertions(+), 7 deletions(-) -- 2.21.0
Re: grace broken installation
On 1/26/2020 10:25 PM, Hans-Bernhard Bröker wrote: > Am 25.01.2020 um 15:23 schrieb Rodrigo Medina: >> Hi, >> Both installations of grace-5.1.24 and grace-5.1.245 are broken. >> /usr/bin/xmgrace.exe runs but gives the message: >> --> Broken or incomplete installation - read the FAQ! >> and then quits. > > After reading the FAQ and comparing with a direct build from upstream > sources, I > find the reason for that is that the FontDataBase file of the distributed > package is, indeed, wrong. > > Apparently the type1 font directory supplied by grace was replaced by a link > to > ghostscript's type1 font repository. But the FontDataBase wasn't updated to > match this change. This mismatch causes xmgrace to baulk. This change was > made > between revisions 5.1.24 and 5.1.25 of the cygwin package, which neatly > explains > why 5.1.24 works, but 5.1.25 does not. See https://cygwin.com/ml/cygwin/2018-03/msg00142.html https://cygwin.com/ml/cygwin/2018-03/msg00156.html 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
[PATCH v2] Cygwin: console: Share readahead buffer within the same process.
- The cause of the problem reported in
https://www.cygwin.com/ml/cygwin/2020-01/msg00220.html is that the
chars input before dup() cannot be read from the new file descriptor.
This is because the readahead buffer (rabuf) in the console is newly
created by dup(), and does not inherit from the parent. This patch
fixes the issue.
---
winsup/cygwin/fhandler.cc | 56 +++
winsup/cygwin/fhandler.h | 33 +-
winsup/cygwin/fhandler_console.cc | 40 +-
winsup/cygwin/fhandler_termios.cc | 35 +--
winsup/cygwin/fhandler_tty.cc | 2 +-
5 files changed, 111 insertions(+), 55 deletions(-)
diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index aeee8fe4d..4210510be 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -44,11 +44,11 @@ void
fhandler_base::reset (const fhandler_base *from)
{
pc << from->pc;
- rabuf = NULL;
- ralen = 0;
- raixget = 0;
- raixput = 0;
- rabuflen = 0;
+ ra.rabuf = NULL;
+ ra.ralen = 0;
+ ra.raixget = 0;
+ ra.raixput = 0;
+ ra.rabuflen = 0;
_refcnt = 0;
}
@@ -66,15 +66,15 @@ int
fhandler_base::put_readahead (char value)
{
char *newrabuf;
- if (raixput < rabuflen)
+ if (raixput () < rabuflen ())
/* Nothing to do */;
- else if ((newrabuf = (char *) realloc (rabuf, rabuflen += 32)))
-rabuf = newrabuf;
+ else if ((newrabuf = (char *) realloc (rabuf (), rabuflen () += 32)))
+rabuf () = newrabuf;
else
return 0;
- rabuf[raixput++] = value;
- ralen++;
+ rabuf ()[raixput ()++] = value;
+ ralen ()++;
return 1;
}
@@ -82,11 +82,11 @@ int
fhandler_base::get_readahead ()
{
int chret = -1;
- if (raixget < ralen)
-chret = ((unsigned char) rabuf[raixget++]) & 0xff;
+ if (raixget () < ralen ())
+chret = ((unsigned char) rabuf ()[raixget ()++]) & 0xff;
/* FIXME - not thread safe */
- if (raixget >= ralen)
-raixget = raixput = ralen = 0;
+ if (raixget () >= ralen ())
+raixget () = raixput () = ralen () = 0;
return chret;
}
@@ -94,10 +94,10 @@ int
fhandler_base::peek_readahead (int queryput)
{
int chret = -1;
- if (!queryput && raixget < ralen)
-chret = ((unsigned char) rabuf[raixget]) & 0xff;
- else if (queryput && raixput > 0)
-chret = ((unsigned char) rabuf[raixput - 1]) & 0xff;
+ if (!queryput && raixget () < ralen ())
+chret = ((unsigned char) rabuf ()[raixget ()]) & 0xff;
+ else if (queryput && raixput () > 0)
+chret = ((unsigned char) rabuf ()[raixput () - 1]) & 0xff;
return chret;
}
@@ -105,7 +105,7 @@ void
fhandler_base::set_readahead_valid (int val, int ch)
{
if (!val)
-ralen = raixget = raixput = 0;
+ralen () = raixget () = raixput () = 0;
if (ch != -1)
put_readahead (ch);
}
@@ -1092,7 +1092,7 @@ fhandler_base::lseek (off_t offset, int whence)
if (whence != SEEK_CUR || offset != 0)
{
if (whence == SEEK_CUR)
- offset -= ralen - raixget;
+ offset -= ralen () - raixget ();
set_readahead_valid (0);
}
@@ -1142,7 +1142,7 @@ fhandler_base::lseek (off_t offset, int whence)
readahead that we have to take into account when calculating
the actual position for the application. */
if (whence == SEEK_CUR)
-res -= ralen - raixget;
+res -= ralen () - raixget ();
return res;
}
@@ -1565,23 +1565,23 @@ fhandler_base::fhandler_base () :
ino (0),
_refcnt (0),
openflags (0),
- rabuf (NULL),
- ralen (0),
- raixget (0),
- raixput (0),
- rabuflen (0),
unique_id (0),
archetype (NULL),
usecount (0)
{
+ ra.rabuf = NULL;
+ ra.ralen = 0;
+ ra.raixget = 0;
+ ra.raixput = 0;
+ ra.rabuflen = 0;
isclosed (false);
}
/* Normal I/O destructor */
fhandler_base::~fhandler_base ()
{
- if (rabuf)
-free (rabuf);
+ if (ra.rabuf)
+free (ra.rabuf);
}
/**/
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index c0d56b4da..b4a5638fe 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -202,16 +202,21 @@ class fhandler_base
ino_t ino; /* file ID or hashed filename, depends on FS. */
LONG _refcnt;
+ public:
+ struct rabuf_t
+ {
+char *rabuf; /* used for crlf conversion in text files */
+size_t ralen;
+size_t raixget;
+size_t raixput;
+size_t rabuflen;
+ };
protected:
/* File open flags from open () and fcntl () calls */
int openflags;
- char *rabuf; /* used for crlf conversion in text files */
- size_t ralen;
- size_t raixget;
- size_t raixput;
- size_t rabuflen;
+ struct rabuf_t ra;
/* Used for advisory file locking. See flock.cc. */
int64_t unique_id;
@@ -315,7 +320,13 @@ class fhandler_base
ReleaseSemaphore (read_state, n, NULL);
}
- bool get_readahead_valid () { return raixget < ralen; }
+ virtual char * () { return ra.rabuf; };
+ virtual
Re: git on mounted CIFS is it Git or Cygwin
On 2020/01/26 13:56, Jason Pyeron wrote: I have an issue with git in Cygwin on windows shares - this is recent (worked months ago). Just to be clear, you are running 'git' on Cygwin and not on linux or some other OS? There is a 'git' that runs on window natively. Have you thought about why you'd want to use the cygwin version of git vs. the windows version since you are running 'git' on the windows machine? I tend to like the cygwin version of things because often it will use the same sources and act the same way as a version on linux, so that's just a comfort and familiarity thing. Depending on your use case, you might want to run git natively using a Win version. Now another question, you say you are running git in Cygwin. Now you say you are running this on a "windows share". What that implies is that the files are being stored on another machine on the network (not locally) that might be a windows machine exporting part of its file system as a 'share', or it could be another OS (like linux) running something like "Samba" to export the disks with a Windows-type network interface (like CIFS). Is there a 3rd machine that is exporting its disks as windows-shares so they can be mounted by windows machines (or other OS's using the CIFS protocol) -- since that is what a 'share' is -- a view of part of a filesystem on that 3rd system. ==OR== is it a local (to the windows machine) disk or partition that most likely has the disk formatted with NTFS. CIFS is a network filesystem interface and has little or nothing to do with cygwin. It can be used between other OS's (linux<->linux for example) to share files or windows<->windows or between different OS's. A guess on my part -- CIFS isn't party of this -- and you are running git storing files on a local hard disk running NTFS and cygwin is emulating posix permissions (ex. 0644) on NTFS. My first guess was something in git had changed, but in writing this out, I think it more likely that it has something to do with 1) your umask settings being set overly restrictively. Created a testdir w/no acls on it. By default it had acls on my system: cd /tmp; mkdir testdir lsacl testdir [u::rwx,g::rwx,g:Untrusted:r-x,m::rwx,o::rwx/u::rwx,g::rwx,g:Untrusted:r-x,m::rwx,o::rwx] testdir # of note: my system created those acls by defaults setup on my system. # Simply creating a directory anywhere on my system will likely have some # ACL's applied by default # so for this test, I removed them: chacl -B testdir lsacl testdir [u::rwx,g::rwx,o::rwx] testdir # above acl corresponds to: ll -da testdir drwxrwxrwx 2 36 Jan 27 03:34 testdir/ (user, group and other all have full access) That was with a umask of 0. Then I created 3 files with my umask set to different settings: umask 0; touch u0 umask 02; touch u02 umask 0377; touch u377 #looking at permission settings: ll testdir total 0 -rw-rw-rw- 1 0 Jan 27 03:33 u0 -rw-rw-r-- 1 0 Jan 27 03:33 u02 -r 1 0 Jan 27 03:34 u377 # Note the last case, gave the user read-only access and nothing to group and other. So something that changed the umask could duplicate your symptoms. So a setting in 'git' might have changed to change the bits in the permissions or in the umask (aside from something changing your default umask value). Depending on where you create a directory it can affect the permissions -- like /tmp is usually set to allow users to create, modify and delete their own files, but not those of other users. Those permissions can change how the file permissions are enforced -- like under tmp, you'd retain write access despite what permissions were on the file, but under a git dir owned by another user, permissions denying write access would be more likely to be strictly enforced. I have narrowed it down to a component of git creating a file as 04xx instead of 06xx permissions. When I do the same with mktemp, I am able to write the file, but git gets a permission denied. I can chmod +w the temp file and then writing works, albeit too late. --- So what umask is there when the file is created, and what permissions does git try to create the file with? Possibly using 'strace' would allow you to see how or why the file is created with the wrong permissions. Also, if you really are working on a network disk -- how you mount and how the disk is exported can also set default permissions and umask effects. There can be ALOT of things that could be causing your problem, BUT, the simplest, and easiest to break w/o knowing it, would be something changing somethign like the umask or default permissions on the directory (i.e. the same symptom could be created by ACLs). Hope this gives you some ideas on what to check -- if lucky it's an easy find, if not, well, could take alot more investigation. good luck! Linda Renaming the file works in either case. What I need help in is determining if this is a bug or a special case of
[PATCH v5] Cygwin: pty: Revise code waiting for forwarding again.
- After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of
cygwin programs which call both printf() and WriteConsole() are
frequently distorted. This patch fixes the issue.
---
winsup/cygwin/fhandler.h | 1 +
winsup/cygwin/fhandler_tty.cc | 37 +--
winsup/cygwin/tty.cc | 1 +
winsup/cygwin/tty.h | 1 +
4 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 35190c0fe..9ce321c8c 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -2209,6 +2209,7 @@ class fhandler_pty_slave: public fhandler_pty_common
}
void setup_locale (void);
void set_freeconsole_on_close (bool val);
+ void wait_pcon_fwd (void);
};
#define __ptsname(buf, unit) __small_sprintf ((buf), "/dev/pty%d", (unit))
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 71a1f42ba..3e5017f19 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -1109,7 +1109,7 @@ skip_console_setting:
}
else if ((fd == 1 || fd == 2) && !get_ttyp ()->switch_to_pcon_out)
{
- cygwait (get_ttyp ()->fwd_done, INFINITE);
+ wait_pcon_fwd ();
if (get_ttyp ()->pcon_pid == 0 ||
kill (get_ttyp ()->pcon_pid, 0) != 0)
get_ttyp ()->pcon_pid = myself->pid;
@@ -1152,7 +1152,7 @@ fhandler_pty_slave::reset_switch_to_pcon (void)
}
if (get_ttyp ()->switch_to_pcon_out)
/* Wait for pty_master_fwd_thread() */
-cygwait (get_ttyp ()->fwd_done, INFINITE);
+wait_pcon_fwd ();
get_ttyp ()->pcon_pid = 0;
get_ttyp ()->switch_to_pcon_in = false;
get_ttyp ()->switch_to_pcon_out = false;
@@ -2680,6 +2680,16 @@ fhandler_pty_slave::set_freeconsole_on_close (bool val)
freeconsole_on_close = val;
}
+void
+fhandler_pty_slave::wait_pcon_fwd (void)
+{
+ acquire_output_mutex (INFINITE);
+ get_ttyp ()->pcon_last_time = GetTickCount ();
+ ResetEvent (get_ttyp ()->fwd_done);
+ release_output_mutex ();
+ cygwait (get_ttyp ()->fwd_done, INFINITE);
+}
+
void
fhandler_pty_slave::fixup_after_attach (bool native_maybe, int fd_set)
{
@@ -2727,7 +2737,7 @@ fhandler_pty_slave::fixup_after_attach (bool
native_maybe, int fd_set)
DWORD mode = ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT;
SetConsoleMode (get_output_handle (), mode);
if (!get_ttyp ()->switch_to_pcon_out)
- cygwait (get_ttyp ()->fwd_done, INFINITE);
+ wait_pcon_fwd ();
if (get_ttyp ()->pcon_pid == 0 ||
kill (get_ttyp ()->pcon_pid, 0) != 0)
get_ttyp ()->pcon_pid = myself->pid;
@@ -3009,14 +3019,29 @@ fhandler_pty_master::pty_master_fwd_thread ()
termios_printf ("Started.");
for (;;)
{
- if (::bytes_available (rlen, from_slave) && rlen == 0)
- SetEvent (get_ttyp ()->fwd_done);
+ if (get_pseudo_console ())
+ {
+ /* The forwarding in pseudo console sometimes stops for
+16-32 msec even if it alerady has data to transfer.
+If the time without transfer exceeds 32 msec, the
+forwarding has supposed to be finished. */
+ const int sleep_in_pcon = 16;
+ const int time_to_wait = sleep_in_pcon * 2 + 1/* margine */;
+ get_ttyp ()->pcon_last_time = GetTickCount ();
+ while (::bytes_available (rlen, from_slave) && rlen == 0)
+ {
+ acquire_output_mutex (INFINITE);
+ if (GetTickCount () - get_ttyp ()->pcon_last_time > time_to_wait)
+ SetEvent (get_ttyp ()->fwd_done);
+ release_output_mutex ();
+ Sleep (1);
+ }
+ }
if (!ReadFile (from_slave, outbuf, sizeof outbuf, , NULL))
{
termios_printf ("ReadFile for forwarding failed, %E");
break;
}
- ResetEvent (get_ttyp ()->fwd_done);
ssize_t wlen = rlen;
char *ptr = outbuf;
if (get_pseudo_console ())
diff --git a/winsup/cygwin/tty.cc b/winsup/cygwin/tty.cc
index ef9bbc1ff..a3d4a0fc8 100644
--- a/winsup/cygwin/tty.cc
+++ b/winsup/cygwin/tty.cc
@@ -246,6 +246,7 @@ tty::init ()
term_code_page = 0;
need_redraw_screen = false;
fwd_done = NULL;
+ pcon_last_time = 0;
}
HANDLE
diff --git a/winsup/cygwin/tty.h b/winsup/cygwin/tty.h
index b291fd3c1..755897d7d 100644
--- a/winsup/cygwin/tty.h
+++ b/winsup/cygwin/tty.h
@@ -107,6 +107,7 @@ private:
UINT term_code_page;
bool need_redraw_screen;
HANDLE fwd_done;
+ DWORD pcon_last_time;
public:
HANDLE from_master () const { return _from_master; }
--
2.21.0
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Jan 27 13:22, Takashi Yano wrote: > On Mon, 27 Jan 2020 11:38:22 +0900 > Takashi Yano wrote: > > On Sun, 26 Jan 2020 22:33:19 +0900 > > Takashi Yano wrote: > > > On Sat, 25 Jan 2020 20:38:37 +0900 > > > Takashi Yano wrote: > > > > On Fri, 24 Jan 2020 12:07:30 +0100 > > > > Corinna Vinschen wrote: > > > > > Too bad. It's pretty strange that CreatePseudoConsole returns a > > > > > valid HPCON but then isn't ready to take input immediately. > > > > > > > > > > > I do not come up with other implementation so far. > > > > > > > > > > > > Let me consider a while. > > > > > > > > > > I wonder how others solve this problem. I see that the native OpenSSH > > > > > is using Sleeps, too, in their start_with_pty() function, calling > > > > > AttachConsole in a loop, but I'm not sure if these are related to > > > > > pseudo > > > > > console usage. The commit message don't explain anything there :( > > > > > > > > The essence of the difficulty is that we have to support both cygwin > > > > programs and native console apps. If we consider only of native console > > > > apps, any time we can use pseudo console. However, pseudo console is > > > > not transparent at all, so it cannot be used for cygwin programs. > > > > > > > > Therefore, current cygwin is switching handles to be used between > > > > named-pipe and pseudo console. > > > > > > > > However, because pseudo console has relatively long latency, if pipe > > > > is switched just after writing to pseudo console, the forwarding > > > > does not get in time. So the "wait" is needed before switching. > > > > > > > > I had tried WriteFile(), ReadFile() and DeviceIoControl() for > > > > HANDLE hConDrvReference, however, all atempts of them failed. > > > > > > After much struggle, I finally found a solution. > > > Please look at v3 patch. > > > > v3 patch does not seem to work as expected in Win10 1809. > > I will submit v4 patch. > > Sorry for again and again. This is tricky stuff. No worries at all. > I think v5 is more fundamental fix than v4. I didn't see a v5 yet. It's still in the works, I take it? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: console: Share readahead buffer within the same process.
Hi Takashi,
On Jan 25 18:45, Takashi Yano wrote:
> - The cause of the problem reported in
> https://www.cygwin.com/ml/cygwin/2020-01/msg00220.html is that the
> chars input before dup() cannot be read from the new file descriptor.
> This is because the readahead buffer (rabuf) in the console is newly
> created by dup(), and does not inherit from the parent. This patch
> fixes the issue.
> ---
> winsup/cygwin/fhandler.cc | 58 ---
> winsup/cygwin/fhandler.h | 24 -
> winsup/cygwin/fhandler_console.cc | 16 -
> winsup/cygwin/fhandler_termios.cc | 35 ++-
> winsup/cygwin/fhandler_tty.cc | 2 +-
> 5 files changed, 80 insertions(+), 55 deletions(-)
>
> diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
> index aeee8fe4d..ad4a7e61c 100644
> --- a/winsup/cygwin/fhandler.cc
> +++ b/winsup/cygwin/fhandler.cc
> @@ -44,11 +44,12 @@ void
> fhandler_base::reset (const fhandler_base *from)
> {
>pc << from->pc;
> - rabuf = NULL;
> - ralen = 0;
> - raixget = 0;
> - raixput = 0;
> - rabuflen = 0;
> + ra.rabuf = NULL;
> + ra.ralen = 0;
> + ra.raixget = 0;
> + ra.raixput = 0;
> + ra.rabuflen = 0;
> + set_rabuf ();
>_refcnt = 0;
> }
>
> @@ -66,15 +67,15 @@ int
> fhandler_base::put_readahead (char value)
> {
>char *newrabuf;
> - if (raixput < rabuflen)
> + if (raptr->raixput < raptr->rabuflen)
> /* Nothing to do */;
This adds extra pointer access to critical code paths, even if only
in O_TEXT scenarios. May I suggest dropping the extra pointer and
converting readahead access to access methods, kind of like this:
class fhandler {
char * () { return ra.rabuf; }
int () { return ra.rabuflen; }
[...]
class fhandler_console {
char * () { return con_ra.rabuf; }
int () { return con_ra.rabuflen; }
[...]
and then use those accessor methods throughout:
> - else if ((newrabuf = (char *) realloc (rabuf, rabuflen += 32)))
> -rabuf = newrabuf;
else if ((newrabuf = (char *) realloc (rabuf (), rabuflen () += 32)))
rabuf () = newrabuf;
etc.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
