Request for additional ming-w64 binaries
I am trying to compile a project under Cygwin with MinGW. After installing some packages from a Cygwin download site, the following packages are missing static libraries, i.e *.a files: mingw64-x86_64-tiff mingw64-x86_64-libjpeg-turbo mingw64-x86_64-fftw3 mingw64-x86_64-libwebp Also this package is not available: mingw64-x86_64-wine Could these binaries be made available? Alternatively, where can I get them? Thank you, PM -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Putting packages up for adoption
Am 27.03.2020 um 21:52 schrieb Yaakov Selkowitz:
On Fri, 2020-03-27 at 18:52 +0100, Marco Atzeri wrote:
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
The plan looks fine. Thanks for it
unfortunately I see unexpected segfault on the testsuite
0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)
for both 2.7.17 and your original 2.7.16.
as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.
3.8.2 seems to stall later in the test, so it is another issue.
In my experience, particularly on Cygwin, the first and most common
cause of testsuite errors are in the tests themselves. While
eventually fixing these would certainly be welcome, I wouldn't block
progress thereon. How does the saying go, "don't let perfection be the
enemy of the good"?
--
Yaakov
usually I follow the same rules, but a bit of investigation
will be needed just to be sure.
Do you know a simple way to go on with the test or skip one ?
particular useful for 3.8.2
6:14:06 load avg: 0.31 running: test_subprocess (6 hour 13 min),
test_asyncio (6 hour 11 min), test_asyncore (6 hour 10 min), test_ssl (6
hour 13 min)
6:14:36 load avg: 0.30 running: test_subprocess (6 hour 13 min),
test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6
hour 14 min)
6:15:06 load avg: 0.41 running: test_subprocess (6 hour 14 min),
test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6
hour 14 min)
Re: WSL symbolic links
On 2020-03-27 12:53, Corinna Vinschen wrote: > On Mar 27 11:58, Brian Inglis wrote: >> On 2020-03-26 14:05, Corinna Vinschen wrote: >>> On Mar 26 13:12, Brian Inglis wrote: On 2020-03-26 05:00, Corinna Vinschen wrote: > On Mar 26 10:00, Thomas Wolff wrote: >> A symbolic link created with WSL is neither interpreted in cygwin nor >> can it >> be deleted: >>> touch file >>> wsl ln -s file link >>> wsl ls -l link >> lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file >>> ls -l link >> -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link > What kind of file are they in the real world? Reparse points? If so, > what content do they have? I attached a Q source from my vault > of old test apps to check on reparse point content. Please compile with > gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll > It takes a single native NT path as parameter, kind of like this: > ./rd-reparse '\??\C:\cygwin64\home\corinna\link' They should be WSL or Windows mklink (soft) links, and the reason why mklink was allowed unelevated in Windows 10 with Developer mode. In an *elevated* shell: $ ls -dln u -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u >>>^ >>> This is unknown user, unknown group, which means, the Windows >>> function LookupAccountSid() probably returned a domain name which >>> is unknown (neither account domain, nor primary, nor trusted domain). >>> >>> An strace of `ls -l u' may be helpful... >> >> Attached with startup environment, locale, and message setup cut (reduced by >> 100KB), and rest sanitized as below. Could DM/PM original on request. > > Thanks! This should already be fixed in the latest developer snapshot > after I was finally able to install WSL myself. See my reply to Thomas > in https://sourceware.org/pipermail/cygwin/2020-March/244211.html > > All the effects are a result of not opening the reparse point as reparse > point, as weird as it sounds at first :) Would you consider that test program a reasonable base for something I have wished for a while: a program that would classify a file name as a (regular) hard link, a Windows directory or file link, a junction, a Windows shortcut, a Cygwin symlink, a Unix/WSL symlink, a URL link, and/or tell me where it links to etc. Thinking of hacking that plus maybe bits of file, cygpath, readshortcut, readlink, lsattr together to display otherwise awkward to access attributes and properties. -- 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: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: dash vs. bash inconsistency
On 3/27/2020 9:09 PM, Sasha Slijepcevic via Cygwin wrote: I am using Cygwin 3.1.4-1, bash 4.4.12-3 and dash 0.5.9.1-1. I have a setup.exe in the root of my Cygwin installation, C:\cygwin64, for example. If I set PATH=C:\cygwin64;C:\cygwin64\bin, I can run setup.exe from bash. C:\>set PATH=C:\cygwin64;C:\cygwin64\bin C:\>bash $ echo $PATH /:/usr/bin $ setup-x86_64.exe --version Cygwin setup 2.903 However, in dash: C:\>dash $ echo $PATH /:/usr/bin $ setup-x86-64.exe --version dash: 2: setup-x86-64.exe: not found Am I misusing Cygwin trying to run executables from the top of the installation? Is it expected to all shells would behave the same? Did you happen to notice that in the second case you misspelled the name of the executable, using a - instead of an _ ? Best - Eliot -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: dash vs. bash inconsistency
Am 28.03.2020 um 02:09 schrieb Sasha Slijepcevic via Cygwin: I am using Cygwin 3.1.4-1, bash 4.4.12-3 and dash 0.5.9.1-1. I have a setup.exe in the root of my Cygwin installation, C:\cygwin64, for example. If I set PATH=C:\cygwin64;C:\cygwin64\bin, I can run setup.exe from bash. C:\>set PATH=C:\cygwin64;C:\cygwin64\bin C:\>bash $ echo $PATH /:/usr/bin $ setup-x86_64.exe --version Cygwin setup 2.903 However, in dash: C:\>dash $ echo $PATH /:/usr/bin $ setup-x86-64.exe --version dash: 2: setup-x86-64.exe: not found Am I misusing Cygwin trying to run executables from the top of the installation? Is it expected to all shells would behave the same? Do you happen to have placed a copy of dash into your assumed root, C:\cygwin64\dash.exe? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
dash vs. bash inconsistency
I am using Cygwin 3.1.4-1, bash 4.4.12-3 and dash 0.5.9.1-1. I have a setup.exe in the root of my Cygwin installation, C:\cygwin64, for example. If I set PATH=C:\cygwin64;C:\cygwin64\bin, I can run setup.exe from bash. C:\>set PATH=C:\cygwin64;C:\cygwin64\bin C:\>bash $ echo $PATH /:/usr/bin $ setup-x86_64.exe --version Cygwin setup 2.903 However, in dash: C:\>dash $ echo $PATH /:/usr/bin $ setup-x86-64.exe --version dash: 2: setup-x86-64.exe: not found Am I misusing Cygwin trying to run executables from the top of the installation? Is it expected to all shells would behave the same? Thanks, Sasha Slijepcevic -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Sv: Sv: Named pipes and multiple writers
On 3/27/2020 6:56 PM, Ken Brown via Cygwin wrote: On 3/27/2020 10:53 AM, sten.kristian.ivars...@gmail.com wrote: On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote: On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote: On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote: The ENIXIO occurs when parallel child-processes simultaneously using O_NONBLOCK opening the descriptor. This is consistent with my guess that the error is generated by fhandler_fifo::wait. I have a feeling that read_ready should have been created as a manual-reset event, and that more care is needed to make sure it's set when it should be. I could provide a code-snippet to reproduce it if wanted ? Yes, please! That might not be necessary. If you're able to build the git repo master branch, please try the attached patch. Here's a better patch. I finally succeeded to build latest master (make is not my favourite tool) and added the patch, but still no success in my little test-program (see attachment) when creating a write-file-descriptor with O_NONBLOCK Your test program fails for me on Linux too. Here's the output from one run: child 657 657 error: 6 No such device or address child 658 child 659 658659 error: child 660 parent child 661 error: 66606661 661 661 error: 661 No such device or address6No such device or address No such device or address [I then killed it with control-C; the parent was blocked trying to open the FIFO.] There's a race condition in your code. The parent is trying to open the FIFO for reading (without O_NONBLOCK) while the child is trying to open it for writing (with O_NONBLOCK). The parent is blocked waiting for the child, and the child's open fails with ENXIO; see https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html#tag_16_357 I think you need to rearrange things so that the FIFO is open for reading before you try a nonblocking open for writing. For example, you could open it with O_RDWR instead of O_RDONLY. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Sv: Sv: Named pipes and multiple writers
On 3/27/2020 10:53 AM, sten.kristian.ivars...@gmail.com wrote: On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote: On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote: On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote: The ENIXIO occurs when parallel child-processes simultaneously using O_NONBLOCK opening the descriptor. This is consistent with my guess that the error is generated by fhandler_fifo::wait. I have a feeling that read_ready should have been created as a manual-reset event, and that more care is needed to make sure it's set when it should be. I could provide a code-snippet to reproduce it if wanted ? Yes, please! That might not be necessary. If you're able to build the git repo master branch, please try the attached patch. Here's a better patch. I finally succeeded to build latest master (make is not my favourite tool) and added the patch, but still no success in my little test-program (see attachment) when creating a write-file-descriptor with O_NONBLOCK Your test program fails for me on Linux too. Here's the output from one run: child 657 657 error: 6 No such device or address child 658 child 659 658659 error: child 660 parent child 661 error: 66606661 661 661 error: 661 No such device or address6No such device or address No such device or address [I then killed it with control-C; the parent was blocked trying to open the FIFO.] There's a race condition in your code. The parent is trying to open the FIFO for reading (without O_NONBLOCK) while the child is trying to open it for writing (with O_NONBLOCK). The parent is blocked waiting for the child, and the child's open fails with ENXIO; see https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html#tag_16_357 I think you need to rearrange things so that the FIFO is open for reading before you try a nonblocking open for writing. I can work around the race by using a small positive 'wait' in fhandler_fifo::wait(), but I'm not sure this is the right thing to do, since Cygwin aims to emulate Linux. Can you find a test case that works on Linux but fails on Cygwin? Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: xterm-353-1
I have uploaded an xterm-353 package, updating from xterm-348. Changes, after taking over maintainership: Added BUILD_DEPENDS to the cygport configuration. Consolidated build parameters, enabling all terminal features (hp-fkeys sco-fkeys dec-locator sixel-graphics regis-graphics). Consolidated runtime dependencies: removed X server fonts Consolidated and tweaked runtime configuration: ! enable consistent ESC prefixing: *VT100*metaSendsEscape: true with best-fit fallbacks *VT100*eightBitInput: true and *VT100*eightBitMeta: true ! BackArrow key sends DEL: *backarrowKeyIsErase: true *ptyInitialErase: true ! encourage terminfo to use true colour: *termName: xterm-direct ! enable Sixel display by default: *decTerminalID: vt340 ! not applying previous restrictions of Red Hat defaults: !*allowFontOps: false !*allowTcapOps: false Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: xterm-353-1
I have uploaded an xterm-353 package, updating from xterm-348. Changes, after taking over maintainership: Added BUILD_DEPENDS to the cygport configuration. Consolidated build parameters, enabling all terminal features (hp-fkeys sco-fkeys dec-locator sixel-graphics regis-graphics). Consolidated runtime dependencies: removed X server fonts Consolidated and tweaked runtime configuration: ! enable consistent ESC prefixing: *VT100*metaSendsEscape: true with best-fit fallbacks *VT100*eightBitInput: true and *VT100*eightBitMeta: true ! BackArrow key sends DEL: *backarrowKeyIsErase: true *ptyInitialErase: true ! encourage terminfo to use true colour: *termName: xterm-direct ! enable Sixel display by default: *decTerminalID: vt340 ! not applying previous restrictions of Red Hat defaults: !*allowFontOps: false !*allowTcapOps: false Thomas
[ANNOUNCEMENT] Updated: algol68g-2.8.4-1
I have uploaded package update algol68g-2.8.4-1. This is the Algol 68 Genie interpreter for the famous orthogonal programming language Algol 68. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: algol68g-2.8.4-1
I have uploaded package update algol68g-2.8.4-1. This is the Algol 68 Genie interpreter for the famous orthogonal programming language Algol 68. Thomas
Unicode data packages: unicode-ucd and unicode-cldr
I have uploaded unicode-ucd-13.0.0-1 - update data files to Unicode13.0 - provide Unihan database files unpacked unicode-cldr-36.1-1 - include all "common" CLDR files - obsoletes package unicode-cldr-emoji-annotations (files are included) - drops pkg-config configuration If the latter causes actual trouble for anyone, please speak up. Thomas
[ANNOUNCEMENT] Unicode data packages: unicode-ucd and unicode-cldr
I have uploaded unicode-ucd-13.0.0-1 - update data files to Unicode13.0 - provide Unihan database files unpacked unicode-cldr-36.1-1 - include all "common" CLDR files - obsoletes package unicode-cldr-emoji-annotations (files are included) - drops pkg-config configuration If the latter causes actual trouble for anyone, please speak up. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Putting packages up for adoption
On Fri, 2020-03-27 at 18:52 +0100, Marco Atzeri wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
> > On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> > > Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > I would suggest the following:
> >
> > * python2-2.7.z continues to provide all '2' symlinks.
> >
> > * python38 be updated to 3.8.2, and 3.8 be designated the next default
> > 'python3' version (with the '3' symlinks continued to be kept
> > separate), and adjust python-wheel.cygclass accordingly.
> >
> > * Similarly, a separate package (in Fedora it's called 'python-
> > unversioned-command') provide unversioned symlinks, pointing to 2.7 for
> > now (for compatibility).
> >
> > * Anything currently dependent on 'python' or 'python2' should either
> > be dropped if no longer needed, switched to 3 is possible, otherwise
> > rebuilt.
> >
> > * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
> > only build those modules that are actually needed by other things by
> > specifying "all".
> >
> > * Once that's done, look at what's still depending on /usr/bin/python
> > ('python-unversioned-command'), and based on that decide when that can
> > be changed to point to python3.
> >
> > HTH,
> >
> > --
> > Yaakov
> >
>
> The plan looks fine. Thanks for it
>
> unfortunately I see unexpected segfault on the testsuite
>
> 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
> 0:00:11 load avg: 1.58 [ 25/404] test_array
> 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> make: *** [Makefile:878: test] Segmentation fault (core dumped)
>
> for both 2.7.17 and your original 2.7.16.
>
> as I saw other segfault on other programs recently
> I assume that one of compiler/binutils/cygwin has some problem.
>
> 3.8.2 seems to stall later in the test, so it is another issue.
In my experience, particularly on Cygwin, the first and most common
cause of testsuite errors are in the tests themselves. While
eventually fixing these would certainly be welcome, I wouldn't block
progress thereon. How does the saying go, "don't let perfection be the
enemy of the good"?
--
Yaakov
Re: "tmux open terminal failed: not a terminal" in terminal emulators other than mintty
On Fri, 27 Mar 2020, 14:29 Kacper Michajlow wrote: > > You can try another pty emulator. F.e. wintty. > > Not really interested in some dead projects ;p > > Let me rephrase the question, because I misspoke. > > Currently Cygwin works acceptably only under Mintty as far as I can see. > Running it from cmd or any of terminal emulators listed before result in > sub-par performance. Even things like Home button to move cursor doesn't > work, as originally stated tmux doesn't work and so on. > > Now that Windows is making improvements to their console > > https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ > it may be good time to improve Cygwin's compatibility. > > Since my first mail I looked at git log and seen pty related changes, > compiled latest Cygwin, but it doesn't work better and even worse, because > mouse stopped working over ssh in tmux. > > That said, I guess my really questions are: > 1. Is the goal to improve Windows console compatibility? > 2. If yes, what is the current status and challenges? > 3. And my original question will the tmux work? :) > > Projects like Windows Terminal are convenient way to have PS, CMD, Cygwin > and its child MSYS in one window hence I am wondering if it will be > possible without drawbacks. > Hi As the maintainer of the tmux Cygwin package I have to admit that I have no idea how to fix this. Sorry. Kind regards Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Putting packages up for adoption
On 27/03/2020 19:10, Yaakov Selkowitz wrote: > On Fri, 2020-03-27 at 18:32 +, Hamish McIntyre-Bhatty via Cygwin- > apps wrote: >> Out of interest, are you also adopting the modules for Python 2 and 3? >> If not, or if you're not keen to adopt all of them, there are a few I'd >> like to adopt (python-wx, python-bs4, and python-pip). > At a minimum, it would probably be easier to coordinate new versions of > Python if one person maintained all the Python versions together with > at least python-setuptools, python-wheel, and python-pip, as those are > the most basic requirements for building Python extensions. > > Someone else has expressed interest in python-wx; perhaps you can work > together on it. > > -- > Yaakov That makes sense. I must have missed that. Who was it? I'm also interested in doing pylint potentially, any reason why that was orphaned before? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Putting packages up for adoption
On Fri, 2020-03-27 at 18:32 +, Hamish McIntyre-Bhatty via Cygwin- apps wrote: > Out of interest, are you also adopting the modules for Python 2 and 3? > If not, or if you're not keen to adopt all of them, there are a few I'd > like to adopt (python-wx, python-bs4, and python-pip). At a minimum, it would probably be easier to coordinate new versions of Python if one person maintained all the Python versions together with at least python-setuptools, python-wheel, and python-pip, as those are the most basic requirements for building Python extensions. Someone else has expressed interest in python-wx; perhaps you can work together on it. -- Yaakov
Re: WSL symbolic links
On Mar 27 11:58, Brian Inglis wrote: > On 2020-03-26 14:05, Corinna Vinschen wrote: > > On Mar 26 13:12, Brian Inglis wrote: > >> On 2020-03-26 05:00, Corinna Vinschen wrote: > >>> On Mar 26 10:00, Thomas Wolff wrote: > A symbolic link created with WSL is neither interpreted in cygwin nor > can it > be deleted: > > touch file > > wsl ln -s file link > > wsl ls -l link > lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file > > ls -l link > -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link > >>> What kind of file are they in the real world? Reparse points? If so, > >>> what content do they have? I attached a Q source from my vault > >>> of old test apps to check on reparse point content. Please compile with > >>> gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll > >>> It takes a single native NT path as parameter, kind of like this: > >>> ./rd-reparse '\??\C:\cygwin64\home\corinna\link' > >> They should be WSL or Windows mklink (soft) links, and the reason why > >> mklink was > >> allowed unelevated in Windows 10 with Developer mode. > >> In an *elevated* shell: > >> $ ls -dln u > >> -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u > >^ > > This is unknown user, unknown group, which means, the Windows > > function LookupAccountSid() probably returned a domain name which > > is unknown (neither account domain, nor primary, nor trusted domain). > > > > An strace of `ls -l u' may be helpful... > > Attached with startup environment, locale, and message setup cut (reduced by > 100KB), and rest sanitized as below. Could DM/PM original on request. Thanks! This should already be fixed in the latest developer snapshot after I was finally able to install WSL myself. See my reply to Thomas in https://sourceware.org/pipermail/cygwin/2020-March/244211.html All the effects are a result of not opening the reparse point as reparse point, as weird as it sounds at first :) Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Putting packages up for adoption
On 27/03/2020 17:53, Marco Atzeri via Cygwin-apps wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
>> On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
>>> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
>
>> I would suggest the following:
>>
>> * python2-2.7.z continues to provide all '2' symlinks.
>>
>> * python38 be updated to 3.8.2, and 3.8 be designated the next default
>> 'python3' version (with the '3' symlinks continued to be kept
>> separate), and adjust python-wheel.cygclass accordingly.
>>
>> * Similarly, a separate package (in Fedora it's called 'python-
>> unversioned-command') provide unversioned symlinks, pointing to 2.7 for
>> now (for compatibility).
>>
>> * Anything currently dependent on 'python' or 'python2' should either
>> be dropped if no longer needed, switched to 3 is possible, otherwise
>> rebuilt.
>>
>> * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
>> only build those modules that are actually needed by other things by
>> specifying "all".
>>
>> * Once that's done, look at what's still depending on /usr/bin/python
>> ('python-unversioned-command'), and based on that decide when that can
>> be changed to point to python3.
>>
>> HTH,
>>
>> --
>> Yaakov
>>
>
> The plan looks fine. Thanks for it
>
> unfortunately I see unexpected segfault on the testsuite
>
> 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle
> skipped
> 0:00:11 load avg: 1.58 [ 25/404] test_array
> 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> make: *** [Makefile:878: test] Segmentation fault (core dumped)
>
> for both 2.7.17 and your original 2.7.16.
>
> as I saw other segfault on other programs recently
> I assume that one of compiler/binutils/cygwin has some problem.
>
> 3.8.2 seems to stall later in the test, so it is another issue.
>
> Regards
> Marco
Marco,
Out of interest, are you also adopting the modules for Python 2 and 3?
If not, or if you're not keen to adopt all of them, there are a few I'd
like to adopt (python-wx, python-bs4, and python-pip).
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: CLDR pkg-config (was: cygport upload)
On 2020-03-27 11:31, Thomas Wolff wrote:
> Am 27.03.2020 um 17:27 schrieb Jon Turney:
>> On 27/03/2020 16:15, Thomas Wolff wrote:
>>> Am 27.03.2020 um 16:41 schrieb Jon Turney:
On 27/03/2020 14:35, Thomas Wolff wrote:
> Am 27.03.2020 um 13:21 schrieb Jon Turney:
>> On 27/03/2020 10:17, Thomas Wolff wrote:
>>> How does cygport upload work?
>>> I previously uploaded with sftp but cygport apparently runs lftp and it
>>> asks me for a password.
>>
>> This just seems to be a thing lftp does.
>>
>> If the key isn't coming from ssh-agent, it always asks for a passphrase.
>> If the key doesn't have one, you can just hit enter (or type anything).
> OK, works. Can lftp or cygport be configured so that lftp does not ask for
> a password? Or to use sftp instead?
I don't know of any configuration for lftp to turn off that behaviour
(which
is arguably a defect in lftp), but that's probably something you could
investigate for yourself.
I am not sure why lftp is used instead of sftp, possibly it is
insufficiently scriptable to do what cygport wants to do.
> Uploading the two Unicode packages, I got this response:
>
> ERROR: package '/sourceware/cygwin-staging/home/Thomas
> Wolff/noarch/release/unicode-cldr' is not in the package list
> ERROR: package '/sourceware/cygwin-staging/home/Thomas
> Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in
> the package list
> SUMMARY: 2 ERROR(s)
Ah, right.
I've updated cygwin-pkg-maint and made the appropriate adjustment.
There still seems to be a problem with the form of the version number
you've
chosen, however.
>>> Yes, calm complains about
>>>
>>> '-' in version
>>>
>>> but 36-1 is the version format used upstream. Do I need to convert it?
>>
>> Looking at http://cldr.unicode.org/index/download, I see it called 36.1
> Right. The download files are provided at https://github.com/unicode-org/cldr
> where you can see release-36-1.
>>
>> The fact that the upstream filename contains '36-1' alone doesn't seem
>> sufficient to grant an exception.
> I think I'll put something like REPOVER=${VERSION//./-} into the cygport file
> for the download then.
>
I am not quite clear how unicode-cldr replaces
unicode-cldr-emoji-annotation, if we have anything which requires it to
build, since it doesn't appear to provide the .pc file that did.
>>> Please elaborate. I do not see any .pc file in the previous package.
>>> The new package include /usr/share/unicode/cldr/common/annotations (which
>>> the
>>> previous one provided solely) and other subdirectories of
>>> /usr/share/unicode/cldr/common.
>>
>> Maybe I am mistaken, but looking at the filelists in
>> https://cygwin.com/packages/summary/unicode-cldr-emoji-annotation.html,
>> package unicode-cldr-emoji-annotation contains
>> /usr/share/pkgconfig/cldr-emoji-annotation.pc
> I wasn't aware of that. Not sure, though, what it's good for. I'd prefer to go
> without it unless it's missed by someone.
It's used mainly for X Window and utility builds with CLDR, and it would be
better and easier just to keep it around with an updated version, if not in the
original upstream package.
--
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.
Re: WSL symbolic links
On 2020-03-26 14:05, Corinna Vinschen wrote: > On Mar 26 13:12, Brian Inglis wrote: >> On 2020-03-26 05:00, Corinna Vinschen wrote: >>> On Mar 26 10:00, Thomas Wolff wrote: A symbolic link created with WSL is neither interpreted in cygwin nor can it be deleted: > touch file > wsl ln -s file link > wsl ls -l link lrwxrwxrwx 1 towo towo 1 Mar 26 08:56 link -> file > ls -l link -rw-r- 1 Unknown+User Unknown+Group 0 Mar 26 00:00 link >>> What kind of file are they in the real world? Reparse points? If so, >>> what content do they have? I attached a Q source from my vault >>> of old test apps to check on reparse point content. Please compile with >>> gcc -g ../src/rd-reparse.c -o rd-reparse -lntdll >>> It takes a single native NT path as parameter, kind of like this: >>> ./rd-reparse '\??\C:\cygwin64\home\corinna\link' >> They should be WSL or Windows mklink (soft) links, and the reason why mklink >> was >> allowed unelevated in Windows 10 with Developer mode. >> In an *elevated* shell: >> $ ls -dln u >> -rw-r- 1 4294967295 4294967295 0 Nov 9 06:09 u >^ > This is unknown user, unknown group, which means, the Windows > function LookupAccountSid() probably returned a domain name which > is unknown (neither account domain, nor primary, nor trusted domain). > > An strace of `ls -l u' may be helpful... Attached with startup environment, locale, and message setup cut (reduced by 100KB), and rest sanitized as below. Could DM/PM original on request. >> $ getfacl u >> getfacl: u: Permission denied >> $ icacls u >> u NULL SID:(DENY)(Rc,S,REA,WEA,X,DC) >> $HOSTNAME\$USER:(F) > ^^^ > Is that the *real* output, or did you tamper with it? Sanitized with a script I use on posted output in case I forget to use aliases like llgo (ls -lgo). Created the script for cygcheck -hrsv output in case I forget, now run from permanent postinstall script in background, as it takes a while if needed, and my desktop environments are messy with stuff from ~/.bash_... setup scripts. -- 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. --- Process 12772 created --- Process 12772 loaded C:\Windows\System32\ntdll.dll at 7ff9e912 --- Process 12772 loaded C:\Windows\System32\kernel32.dll at 7ff9e732 --- Process 12772 loaded C:\Windows\System32\KernelBase.dll at 7ff9e6d3 --- Process 12772 thread 5544 created --- Process 12772 thread 7184 created --- Process 12772 loaded C:\...\cygwin64\bin\cygwin1.dll at 00018004 --- Process 12772 loaded C:\...\cygwin64\bin\cygintl-8.dll at 0003c49c --- Process 12772 thread 15324 created --- Process 12772 loaded C:\...\cygwin64\bin\cygiconv-2.dll at 0003d72e 0 0 [main] ls (12772) ** 274 274 [main] ls (12772) Program name: C:\...\cygwin64\bin\ls.exe (windows pid 12772) 59 333 [main] ls (12772) OS version: Windows NT-10.0 61 394 [main] ls (12772) ** --- Process 12772 loaded C:\Windows\System32\advapi32.dll at 7ff9e78e --- Process 12772 loaded C:\Windows\System32\msvcrt.dll at 7ff9e86d --- Process 12772 loaded C:\Windows\System32\sechost.dll at 7ff9e8a4 --- Process 12772 loaded C:\Windows\System32\rpcrt4.dll at 7ff9e8fc --- Process 12772 loaded C:\Windows\System32\cryptbase.dll at 7ff9e59c --- Process 12772 loaded C:\Windows\System32\bcryptprimitives.dll at 7ff9e626 ... 4047 83868 [main] ls 25955 lstat64: entering 64 83932 [main] ls 25955 normalize_posix_path: src u 42 83974 [main] ls 25955 cwdstuff::get: posix /home/$USER 41 84015 [main] ls 25955 cwdstuff::get: (/home/$USER) = cwdstuff::get (0x80010, 32768, 1, 0), errno 0 42 84057 [main] ls 25955 normalize_posix_path: /home/$USER/u = normalize_posix_path (u) 41 84098 [main] ls 25955 mount_info::conv_to_win32_path: conv_to_win32_path (/home/$USER/u) 42 84140 [main] ls 25955 mount_info::cygdrive_win32_path: src '/home/$USER/u', dst 'C:\Users\$USER\u' 43 84183 [main] ls 25955 mount_info::conv_to_win32_path: src_path /home/$USER/u, dst C:\Users\$USER\u, flags 0x4028, rc 0 115 84298 [main] ls 25955 symlink_info::check: 0x0 = NtCreateFile (\??\C:\Users\$USER\u) 93 84391 [main] ls 25955 symlink_info::check: not a symlink 96 84487 [main] ls 25955 symlink_info::check: 0 = symlink.check(C:\Users\$USER\u, 0xB700) (mount_flags 0x4028, path_flags 0x0) 53 84540 [main] ls 25955 path_conv::check: this->path(C:\Users\$USER\u), has_acls(1) 47 84587 [main] ls 25955 build_fh_pc: fh 0x18034C1E0, dev 00C3 41 84628 [main] ls 25955 stat_worker: (\??\C:\Users\$USER\u, 0x8000986E0, 0x18034C1E0), file_attributes 32 44 84672
Re: Putting packages up for adoption
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
The plan looks fine. Thanks for it
unfortunately I see unexpected segfault on the testsuite
0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)
for both 2.7.17 and your original 2.7.16.
as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.
3.8.2 seems to stall later in the test, so it is another issue.
Regards
Marco
Re: Putting packages up for adoption
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
The plan looks fine. Thanks for it
unfortunately I see unexpected segfault on the testsuite
0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)
for both 2.7.17 and your original 2.7.16.
as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.
3.8.2 seems to stall later in the test, so it is another issue.
Regards
Marco
Re: FYI: avast claims setup threat
On Fri, Mar 27, 2020 at 11:35 AM Ernie Rael wrote: > I just downloaded most recent setup-x86_64, v2.903. Avast was not happy. > > Threat name: IDP.Generic > > I did check with pgp2 --verify before I tried it. Report it to Avast as a false-positive. Bill -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: gnu make broken?
Am 27.03.2020 um 18:21 schrieb Ryan Johnson: Hi all, Running `make` for the first time in over a year, it exits silently without doing anything at all. Running `strace make` pops up the following windows alert: The procedure entry point sched_getaffinity could not be located in the dynamic link library C:\cygwin64\bin\cygguile-2.2-1.dll I recently had to downgrade to cygwin-3.0.7 dll, because 3.1 causes emacs gud issues... is that a possible reason? likely yes. You can try to also downgrade make to 4.2.1 Thanks, Ryan -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
FYI: avast claims setup threat
I just downloaded most recent setup-x86_64, v2.903. Avast was not happy. Threat name: IDP.Generic I did check with pgp2 --verify before I tried it. -ernie -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport upload
Am 27.03.2020 um 17:27 schrieb Jon Turney:
On 27/03/2020 16:15, Thomas Wolff wrote:
Am 27.03.2020 um 16:41 schrieb Jon Turney:
On 27/03/2020 14:35, Thomas Wolff wrote:
Am 27.03.2020 um 13:21 schrieb Jon Turney:
On 27/03/2020 10:17, Thomas Wolff wrote:
How does cygport upload work?
I previously uploaded with sftp but cygport apparently runs lftp
and it asks me for a password.
This just seems to be a thing lftp does.
If the key isn't coming from ssh-agent, it always asks for a
passphrase. If the key doesn't have one, you can just hit enter
(or type anything).
OK, works. Can lftp or cygport be configured so that lftp does not
ask for a password? Or to use sftp instead?
I don't know of any configuration for lftp to turn off that
behaviour (which is arguably a defect in lftp), but that's probably
something you could investigate for yourself.
I am not sure why lftp is used instead of sftp, possibly it is
insufficiently scriptable to do what cygport wants to do.
Uploading the two Unicode packages, I got this response:
ERROR: package '/sourceware/cygwin-staging/home/Thomas
Wolff/noarch/release/unicode-cldr' is not in the package list
ERROR: package '/sourceware/cygwin-staging/home/Thomas
Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is
not in the package list
SUMMARY: 2 ERROR(s)
Ah, right.
I've updated cygwin-pkg-maint and made the appropriate adjustment.
There still seems to be a problem with the form of the version
number you've chosen, however.
Yes, calm complains about
'-' in version
but 36-1 is the version format used upstream. Do I need to convert it?
Looking at http://cldr.unicode.org/index/download, I see it called 36.1
Right. The download files are provided at
https://github.com/unicode-org/cldr where you can see release-36-1.
The fact that the upstream filename contains '36-1' alone doesn't seem
sufficient to grant an exception.
I think I'll put something like REPOVER=${VERSION//./-} into the cygport
file for the download then.
I am not quite clear how unicode-cldr replaces
unicode-cldr-emoji-annotation, if we have anything which requires it
to build, since it doesn't appear to provide the .pc file that did.
Please elaborate. I do not see any .pc file in the previous package.
The new package include /usr/share/unicode/cldr/common/annotations
(which the previous one provided solely) and other subdirectories of
/usr/share/unicode/cldr/common.
Maybe I am mistaken, but looking at the filelists in
https://cygwin.com/packages/summary/unicode-cldr-emoji-annotation.html,
package unicode-cldr-emoji-annotation contains
/usr/share/pkgconfig/cldr-emoji-annotation.pc
I wasn't aware of that. Not sure, though, what it's good for. I'd prefer
to go without it unless it's missed by someone.
Thomas
Re: cygport upload
On 27/03/2020 16:15, Thomas Wolff wrote: Am 27.03.2020 um 16:41 schrieb Jon Turney: On 27/03/2020 14:35, Thomas Wolff wrote: Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? I don't know of any configuration for lftp to turn off that behaviour (which is arguably a defect in lftp), but that's probably something you could investigate for yourself. I am not sure why lftp is used instead of sftp, possibly it is insufficiently scriptable to do what cygport wants to do. Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s) Ah, right. I've updated cygwin-pkg-maint and made the appropriate adjustment. There still seems to be a problem with the form of the version number you've chosen, however. Yes, calm complains about '-' in version but 36-1 is the version format used upstream. Do I need to convert it? Looking at http://cldr.unicode.org/index/download, I see it called 36.1 The fact that the upstream filename contains '36-1' alone doesn't seem sufficient to grant an exception. I am not quite clear how unicode-cldr replaces unicode-cldr-emoji-annotation, if we have anything which requires it to build, since it doesn't appear to provide the .pc file that did. Please elaborate. I do not see any .pc file in the previous package. The new package include /usr/share/unicode/cldr/common/annotations (which the previous one provided solely) and other subdirectories of /usr/share/unicode/cldr/common. Maybe I am mistaken, but looking at the filelists in https://cygwin.com/packages/summary/unicode-cldr-emoji-annotation.html, package unicode-cldr-emoji-annotation contains /usr/share/pkgconfig/cldr-emoji-annotation.pc
Re: cygport upload
Am 27.03.2020 um 16:41 schrieb Jon Turney: On 27/03/2020 14:35, Thomas Wolff wrote: Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? I don't know of any configuration for lftp to turn off that behaviour (which is arguably a defect in lftp), but that's probably something you could investigate for yourself. I am not sure why lftp is used instead of sftp, possibly it is insufficiently scriptable to do what cygport wants to do. Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s) Ah, right. I've updated cygwin-pkg-maint and made the appropriate adjustment. There still seems to be a problem with the form of the version number you've chosen, however. Yes, calm complains about '-' in version but 36-1 is the version format used upstream. Do I need to convert it? I am not quite clear how unicode-cldr replaces unicode-cldr-emoji-annotation, if we have anything which requires it to build, since it doesn't appear to provide the .pc file that did. Please elaborate. I do not see any .pc file in the previous package. The new package include /usr/share/unicode/cldr/common/annotations (which the previous one provided solely) and other subdirectories of /usr/share/unicode/cldr/common. Thomas
Re: ACL: Why SYSTEM doesn't have full access set on newly created files?
Greetings, Kacper Michajlow! >> It is easily fixable by mounting directories outside Cygwin tree with >> "noacl" flag. >> It is even required to do so, if you expect interoperation between Cygwin >> and native tools. > Indeed, this is acceptable workaround for me. Then again it is not really > interoperable out of the box, even tho it may looks like. Interoperabily with native tools was never a stated goal of Cygwin project. Although it is trying to comply where possible. > I mean all Windows drives are mounted, you can easily jump through all > directories, mess with them until you find that it doesn't work and it is " > required" to access those files differently. One may be fooled by the > seemingly no boundary between Cygwin and Windows. I can agree that default /cygdrive mount options needs a revision. >> Don't do that on Cygwin directory tree, you break Cygwin doing this. > I was talking about project cloned outside Cygwin tree, by using Cygwin's > git. I do understand that Cygwin sysroot is it's own thing. > Also the Cygwin tree have let say "normal" permissions set. I mean there is > not deny on SYSTEM and so on. >> Answered multiple time in the last 20 years. Read the docs. > If it were so easy to find. And it was changed like 5 years ago how ACLs > are handled, so I really doubt it was described 20 years ago. I just wanted > to understand why SYSTEM described in Cygwin's docs as "A special account > which has all kinds of dangerous rights, sort of an uber-root account." > have those rights limited. If you find documentation incorrect or unclear, please ask any questions you have or suggest patches. >> They are in correct order. Just not canonical order, which Explorer only >> supports. > I was not implying they are in incorrect order... The question was, could > Cygwin apart from having permissions in correct order, have them in > Explorer compatible order also? As I said, if you fix /cygdrive mount options to include noacl flag, permissions control will be deferred to operating system. This will amend some of the interoperability issues. -- With best regards, Andrey Repin Friday, March 27, 2020 18:19:43 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport upload
On 27/03/2020 14:35, Thomas Wolff wrote: Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? I don't know of any configuration for lftp to turn off that behaviour (which is arguably a defect in lftp), but that's probably something you could investigate for yourself. I am not sure why lftp is used instead of sftp, possibly it is insufficiently scriptable to do what cygport wants to do. Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s) Ah, right. I've updated cygwin-pkg-maint and made the appropriate adjustment. There still seems to be a problem with the form of the version number you've chosen, however. I am not quite clear how unicode-cldr replaces unicode-cldr-emoji-annotation, if we have anything which requires it to build, since it doesn't appear to provide the .pc file that did.
Sv: Sv: Sv: Named pipes and multiple writers
>On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>> On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote:
The ENIXIO occurs when parallel child-processes simultaneously using
O_NONBLOCK opening the descriptor.
>>>
>>> This is consistent with my guess that the error is generated by
>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>> been created as a manual-reset event, and that more care is needed to
>>> make sure it's set when it should be.
>>>
I could provide a code-snippet
to reproduce it if wanted ?
>>>
>>> Yes, please!
>>
>> That might not be necessary. If you're able to build the git repo
>> master branch, please try the attached patch.
>Here's a better patch.
I finally succeeded to build latest master (make is not my favourite tool)
and added the patch, but still no success in my little test-program (see
attachment) when creating a write-file-descriptor with O_NONBLOCK
>Ken
#include
#include
#include
#include
#include
#include
#include
namespace
{
auto error(const int error)
{
std::cerr << getpid() << "\terror:\t" << error << '\t' <<
std::strerror(error) << std::endl;
return error;
}
}
int main()
{
const auto name{"/tmp/my_name"};
const auto result = mkfifo(name, 0666);
if(result) return error(errno);
constexpr auto writers{5};
constexpr auto messages{4};
for(auto idx = 0; idx < writers; ++idx)
{
const auto pid = fork();
if(pid < 0) return error(errno);
if(pid == 0)
{
std::cout << "child " << getpid() << std::endl;
for(auto idx = 0; idx < messages; ++idx)
{
const auto wfd = open(name, O_WRONLY | O_NONBLOCK);
if(wfd < 0) return error(errno);
const auto msg{std::to_string(getpid())};
if(write(wfd, msg.data(), msg.size() + 1) < 0) error(errno);
close(wfd);
}
return 0;
}
}
{
std::cout << "parent" << std::endl;
const auto rfd = open(name, O_RDONLY);
const auto wfd = open(name, O_WRONLY);
if(rfd < 0) return error(errno);
for(auto idx = 0; idx < writers * messages; ++idx)
{
std::string buffer;
buffer.resize(80);
if(read(rfd, [0], buffer.size()) < 0) error(errno);
std::cout << buffer << std::endl;
}
close(wfd);
close(rfd);
}
if(unlink(name) < 0) return error(errno);
return 0;
}--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
Am 27.03.2020 um 14:01 schrieb Corinna Vinschen: On Mar 27 13:24, Thomas Wolff wrote: Am 27.03.2020 um 12:21 schrieb Corinna Vinschen: On Mar 27 00:52, Thomas Wolff wrote: [...] rd-reparse '\??\C:\tmp\link' ; echo ReparseTag: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 rd-reparse '\??\C:\tmp\link-abs' ; echo ReparseTag: 0xa01d ReparseDataLength: 19 Reserved: 0 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 69 6c 65 rd-reparse '\??\C:\tmp\link-foo' ; echo ReparseTag: 0xa01d ReparseDataLength: 9 Reserved: 0 02 00 00 00 66 c3 b6 c3 b6 rd-reparse '\??\C:\tmp\link-foo-abs' ; echo ReparseTag: 0xa01d ReparseDataLength: 20 Reserved: 0 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 c3 b6 c3 b6 [...] I debugged this now and I found that practically all problems, including the inability to delete the symlink, are a result of not being able to open the reparse point correctly as reparse point within Cygwin. So as not to destroy something important, Cygwin only opens reparse points as reparse points if it recognizes the reparse point type. Consequentially, all immediate problems go away, as soon as Cygwin recognizes and handles the symlink :) So I created a patch and pushed it. The latest developer snapshot from https://cygwin.com/snapshots/ contains this patch. Works, great, thank you! Thanks for testing! Funny sidenote: Assuming you create symlinks pointing to files with non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts *all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd. I assume this will also happen if you try to create the file with these chars in the first place, so it's not much of a problem. As Windows filenames are character strings as opposed to Linux filenames which are byte strings, some strange behaviour is unavoidable. I see: $ wsl ls -l link_LW lrwxrwxrwx 1 towo towo 19 Mar 27 12:11 link_LW -> file_L_ $ ls -l link_LW lrwxrwxrwx 1 towo Kein 11 27. Mrz 13:11 link_LW -> file_L_ which looks OK for me. Not sure I expressed myself correctly there. What I was trying to say is, the symlink created by WSL already contains the 0xfffd replacement char, in UTF-8 \xef \xbf \xbd. So the info is already lost inside the symlink. I couldn't create a non-UTF8 file name in WSL on the command line; even running LC_ALL=de_DE mintty and running WSL LC_ALL=de_DE bash, keyboard input would still appear as UTF-8 when displayed with od, which is weird. Anyway, this can be tricked using touch from a script file of course. In that case, indeed WSL flattens all invalid characters to � already for the filename. However, all symbolic link cases work for me. I can point links to file_L_ and file_LW_ and access the respective files correctly via the links from both WSL and cygwin now. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport upload
Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s)
Re: Requesting a new version of GNU ddrescue
So, I went ahead and made a package, and it's available at https://www.hamishmb.com/files/cygwin-temp/. Does anyone mind checking for me that I've done this right, just so I can get the technique down before I try to package anything complicated? Hamish On 25/03/2020 11:53, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > Hello, > > I would like to request that GNU ddrescue 1.25 be packages for Cygwin. I > would be happy to produce this package if that would be appropriate - > I'd like to start with a simpler package before moving on to wxwidgets > and wxpython. > > Hamish > 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: "tmux open terminal failed: not a terminal" in terminal emulators other than mintty
> You can try another pty emulator. F.e. wintty. Not really interested in some dead projects ;p Let me rephrase the question, because I misspoke. Currently Cygwin works acceptably only under Mintty as far as I can see. Running it from cmd or any of terminal emulators listed before result in sub-par performance. Even things like Home button to move cursor doesn't work, as originally stated tmux doesn't work and so on. Now that Windows is making improvements to their console https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ it may be good time to improve Cygwin's compatibility. Since my first mail I looked at git log and seen pty related changes, compiled latest Cygwin, but it doesn't work better and even worse, because mouse stopped working over ssh in tmux. That said, I guess my really questions are: 1. Is the goal to improve Windows console compatibility? 2. If yes, what is the current status and challenges? 3. And my original question will the tmux work? :) Projects like Windows Terminal are convenient way to have PS, CMD, Cygwin and its child MSYS in one window hence I am wondering if it will be possible without drawbacks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: Sv: Named pipes and multiple writers
On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote:
The ENIXIO occurs when parallel child-processes simultaneously using
O_NONBLOCK opening the descriptor.
This is consistent with my guess that the error is generated by
fhandler_fifo::wait. I have a feeling that read_ready should have been
created as a manual-reset event, and that more care is needed to make sure
it's set when it should be.
I could provide a code-snippet
to reproduce it if wanted ?
Yes, please!
That might not be necessary. If you're able to build the git repo master
branch, please try the attached patch.
Here's a better patch.
Ken
>From 3efd5a8cbff8d48b8cf9807070134bb79f591b7d Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Thu, 26 Mar 2020 19:02:16 -0400
Subject: [PATCH] Cygwin: FIFO: fix a problem opening nonblocking writers
Make read_ready a manual-reset event. Previously, when it was an
auto-reset event, there was a brief period when read_ready was not set
after a writer opened. An attempt to open a second writer during this
period would fail with ENXIO if O_NONBLOCK was set, even if a reader
was open.
For the same reason, move ResetEvent(read_ready) from
listen_client_thread() to close().
Addresses: https://sourceware.org/pipermail/cygwin/2020-March/244201.html
---
winsup/cygwin/fhandler_fifo.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index 19cd0e507..c7e27e883 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -463,7 +463,6 @@ fhandler_fifo::listen_client_thread ()
out:
if (evt)
CloseHandle (evt);
- ResetEvent (read_ready);
if (ret < 0)
debug_printf ("exiting with error, %E");
else
@@ -516,7 +515,7 @@ fhandler_fifo::open (int flags, mode_t)
char npbuf[MAX_PATH];
__small_sprintf (npbuf, "r-event.%08x.%016X", get_dev (), get_ino ());
- if (!(read_ready = CreateEvent (sa_buf, false, false, npbuf)))
+ if (!(read_ready = CreateEvent (sa_buf, true, false, npbuf)))
{
debug_printf ("CreateEvent for %s failed, %E", npbuf);
res = error_set_errno;
@@ -1016,6 +1015,8 @@ fhandler_fifo::close ()
handler or another thread. */
fifo_client_unlock ();
int ret = stop_listen_client ();
+ if (reader && read_ready)
+ResetEvent (read_ready);
if (read_ready)
CloseHandle (read_ready);
if (write_ready)
--
2.21.0
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
On Mar 27 13:24, Thomas Wolff wrote: > Am 27.03.2020 um 12:21 schrieb Corinna Vinschen: > > On Mar 27 00:52, Thomas Wolff wrote: > > > [...] > > > > rd-reparse '\??\C:\tmp\link' ; echo > > > ReparseTag: 0xa01d > > > ReparseDataLength: 8 > > > Reserved: 0 > > > 02 00 00 00 66 69 6c 65 > > > > rd-reparse '\??\C:\tmp\link-abs' ; echo > > > ReparseTag: 0xa01d > > > ReparseDataLength: 19 > > > Reserved: 0 > > > 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 > > > 69 6c 65 > > > > rd-reparse '\??\C:\tmp\link-foo' ; echo > > > ReparseTag: 0xa01d > > > ReparseDataLength: 9 > > > Reserved: 0 > > > 02 00 00 00 66 c3 b6 c3 b6 > > > > rd-reparse '\??\C:\tmp\link-foo-abs' ; echo > > > ReparseTag: 0xa01d > > > ReparseDataLength: 20 > > > Reserved: 0 > > > 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 > > > c3 b6 c3 b6 > > [...] > > I debugged this now and I found that practically all problems, including > > the inability to delete the symlink, are a result of not being able to > > open the reparse point correctly as reparse point within Cygwin. So as > > not to destroy something important, Cygwin only opens reparse points as > > reparse points if it recognizes the reparse point type. > > > > Consequentially, all immediate problems go away, as soon as Cygwin > > recognizes and handles the symlink :) > > > > So I created a patch and pushed it. The latest developer snapshot from > > https://cygwin.com/snapshots/ contains this patch. > Works, great, thank you! Thanks for testing! > > Funny sidenote: Assuming you create symlinks pointing to files with > > non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts > > *all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd. I assume > > this will also happen if you try to create the file with these chars in > > the first place, so it's not much of a problem. > As Windows filenames are character strings as opposed to Linux filenames > which are byte strings, some strange behaviour is unavoidable. I see: > $ wsl ls -l link_LW > lrwxrwxrwx 1 towo towo 19 Mar 27 12:11 link_LW -> > file_L_ > $ ls -l link_LW > lrwxrwxrwx 1 towo Kein 11 27. Mrz 13:11 link_LW -> file_L_ > which looks OK for me. Not sure I expressed myself correctly there. What I was trying to say is, the symlink created by WSL already contains the 0xfffd replacement char, in UTF-8 \xef \xbf \xbd. So the info is already lost inside the symlink. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ACL: Why SYSTEM doesn't have full access set on newly created files?
> It is easily fixable by mounting directories outside Cygwin tree with "noacl" flag. > It is even required to do so, if you expect interoperation between Cygwin and > native tools. Indeed, this is acceptable workaround for me. Then again it is not really interoperable out of the box, even tho it may looks like. I mean all Windows drives are mounted, you can easily jump through all directories, mess with them until you find that it doesn't work and it is " required" to access those files differently. One may be fooled by the seemingly no boundary between Cygwin and Windows. > Don't do that on Cygwin directory tree, you break Cygwin doing this. I was talking about project cloned outside Cygwin tree, by using Cygwin's git. I do understand that Cygwin sysroot is it's own thing. Also the Cygwin tree have let say "normal" permissions set. I mean there is not deny on SYSTEM and so on. > Answered multiple time in the last 20 years. Read the docs. If it were so easy to find. And it was changed like 5 years ago how ACLs are handled, so I really doubt it was described 20 years ago. I just wanted to understand why SYSTEM described in Cygwin's docs as "A special account which has all kinds of dangerous rights, sort of an uber-root account." have those rights limited. > They are in correct order. Just not canonical order, which Explorer only supports. I was not implying they are in incorrect order... The question was, could Cygwin apart from having permissions in correct order, have them in Explorer compatible order also? > Yes. Thank you for comprehensive answer. -Kacper -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Use cygwin to run autotools for MSVC?
Hi Mike, > Is it possible use Cygwin to run an autotools 'configure' script but > have the compiler be MSVC? Yeah, sure, i have done this in the past. "./configure CC=cl.exe" should get you going as far as i remember. Make sure your MS tools are in your PATH. There are limitations though, as some of library search mechanisms in autoconf will not work as expected, so do not expect larger projects to work without having to hack a bit in those nasty M4 macro files (yikes!). But for simple projects it does actually work, which is what i used it for. I have not tried it recently, but i guess it still is supported. Thanks, /pedro -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: WSL symbolic links
Am 27.03.2020 um 12:21 schrieb Corinna Vinschen: On Mar 27 00:52, Thomas Wolff wrote: Am 26.03.2020 um 20:56 schrieb Corinna Vinschen: This is a reparse point tag different from the normal Windows symlink reparse point tag, 0xa00c. Searching for this value shows this is defined in ntifs.h as IO_REPARSE_TAG_LX_SYMLINK. Unfortunately I don't see a definition of the reparse point data for that reparse point type. In your examples the data part looks like a 4 byte int value, being 2 in both of your examples, maybe a file type, followed by the path in multibyte, no trailing \0. Unfortunately, in both cases the path is relative, just the file name it points to. To get more information, could one of you two please create a few more symlinks? - A symlink pointing to a local path, given in absolute path syntax. I assume the path will be in POSIX syntax, contain slashes, but it would be helpful to see it. - A symlink with a target path pointing to a remote file (what syntax does this use?) - Last but not least, could you please create a symlink pointing to a target with a non-ASCII char, e. g., some german umlaut? Not sure what kind of remote you'd like to see. I have a 'net use' (cifs/smbfs) mounted drive but couldn't mount it in WSL. Otherwise: wsl -d Ubuntu ls -l link* lrwxrwxrwx 1 towo towo 4 Mar 27 00:31 link -> file lrwxrwxrwx 1 towo towo 15 Mar 27 00:31 link-abs -> /mnt/c/tmp/file lrwxrwxrwx 1 towo towo 5 Mar 27 00:39 link-foo -> föö lrwxrwxrwx 1 towo towo 16 Mar 27 00:39 link-foo-abs -> /mnt/c/tmp/föö rd-reparse '\??\C:\tmp\link' ; echo ReparseTag: 0xa01d ReparseDataLength: 8 Reserved: 0 02 00 00 00 66 69 6c 65 rd-reparse '\??\C:\tmp\link-abs' ; echo ReparseTag: 0xa01d ReparseDataLength: 19 Reserved: 0 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 69 6c 65 rd-reparse '\??\C:\tmp\link-foo' ; echo ReparseTag: 0xa01d ReparseDataLength: 9 Reserved: 0 02 00 00 00 66 c3 b6 c3 b6 rd-reparse '\??\C:\tmp\link-foo-abs' ; echo ReparseTag: 0xa01d ReparseDataLength: 20 Reserved: 0 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 c3 b6 c3 b6 Thanks! In the meantime I could fix my problems with the Windows Store and was finally able to install WSL for further testing. See below. If the link name itself contains non-ASCII, rd-reparse fails with NtOpenFile: C034 Yeah, that's expected. The test app only handles filename with ASCII chars. It's questionable if supporting this new symlink type makes sense, but taking a closer look doesn't hurt, I guess. Well, at least they should be deletable, I think. I debugged this now and I found that practically all problems, including the inability to delete the symlink, are a result of not being able to open the reparse point correctly as reparse point within Cygwin. So as not to destroy something important, Cygwin only opens reparse points as reparse points if it recognizes the reparse point type. Consequentially, all immediate problems go away, as soon as Cygwin recognizes and handles the symlink :) So I created a patch and pushed it. The latest developer snapshot from https://cygwin.com/snapshots/ contains this patch. Works, great, thank you! Funny sidenote: Assuming you create symlinks pointing to files with non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts *all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd. I assume this will also happen if you try to create the file with these chars in the first place, so it's not much of a problem. As Windows filenames are character strings as opposed to Linux filenames which are byte strings, some strange behaviour is unavoidable. I see: $ wsl ls -l link_LW lrwxrwxrwx 1 towo towo 19 Mar 27 12:11 link_LW -> file_L_ $ ls -l link_LW lrwxrwxrwx 1 towo Kein 11 27. Mrz 13:11 link_LW -> file_L_ which looks OK for me. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport upload
On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything).
Re: WSL symbolic links
On Mar 27 00:52, Thomas Wolff wrote: > Am 26.03.2020 um 20:56 schrieb Corinna Vinschen: > > This is a reparse point tag different from the normal Windows symlink > > reparse point tag, 0xa00c. Searching for this value shows this > > is defined in ntifs.h as IO_REPARSE_TAG_LX_SYMLINK. > > > > Unfortunately I don't see a definition of the reparse point data for > > that reparse point type. > > > > In your examples the data part looks like a 4 byte int value, being 2 in > > both of your examples, maybe a file type, followed by the path in > > multibyte, no trailing \0. > > > > Unfortunately, in both cases the path is relative, just the file name it > > points to. To get more information, could one of you two please create > > a few more symlinks? > > > > - A symlink pointing to a local path, given in absolute path syntax. > >I assume the path will be in POSIX syntax, contain slashes, but it > >would be helpful to see it. > > > > - A symlink with a target path pointing to a remote file (what syntax > >does this use?) > > > > - Last but not least, could you please create a symlink pointing to a > >target with a non-ASCII char, e. g., some german umlaut? > Not sure what kind of remote you'd like to see. I have a 'net use' > (cifs/smbfs) mounted drive but couldn't mount it in WSL. Otherwise: > > > wsl -d Ubuntu ls -l link* > lrwxrwxrwx 1 towo towo 4 Mar 27 00:31 link -> file > lrwxrwxrwx 1 towo towo 15 Mar 27 00:31 link-abs -> /mnt/c/tmp/file > lrwxrwxrwx 1 towo towo 5 Mar 27 00:39 link-foo -> föö > lrwxrwxrwx 1 towo towo 16 Mar 27 00:39 link-foo-abs -> /mnt/c/tmp/föö > > rd-reparse '\??\C:\tmp\link' ; echo > ReparseTag: 0xa01d > ReparseDataLength: 8 > Reserved: 0 > 02 00 00 00 66 69 6c 65 > > rd-reparse '\??\C:\tmp\link-abs' ; echo > ReparseTag: 0xa01d > ReparseDataLength: 19 > Reserved: 0 > 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 > 69 6c 65 > > rd-reparse '\??\C:\tmp\link-foo' ; echo > ReparseTag: 0xa01d > ReparseDataLength: 9 > Reserved: 0 > 02 00 00 00 66 c3 b6 c3 b6 > > rd-reparse '\??\C:\tmp\link-foo-abs' ; echo > ReparseTag: 0xa01d > ReparseDataLength: 20 > Reserved: 0 > 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66 > c3 b6 c3 b6 Thanks! In the meantime I could fix my problems with the Windows Store and was finally able to install WSL for further testing. See below. > If the link name itself contains non-ASCII, rd-reparse fails with > NtOpenFile: C034 Yeah, that's expected. The test app only handles filename with ASCII chars. > > It's questionable if supporting this new symlink type makes sense, but > > taking a closer look doesn't hurt, I guess. > Well, at least they should be deletable, I think. I debugged this now and I found that practically all problems, including the inability to delete the symlink, are a result of not being able to open the reparse point correctly as reparse point within Cygwin. So as not to destroy something important, Cygwin only opens reparse points as reparse points if it recognizes the reparse point type. Consequentially, all immediate problems go away, as soon as Cygwin recognizes and handles the symlink :) So I created a patch and pushed it. The latest developer snapshot from https://cygwin.com/snapshots/ contains this patch. Funny sidenote: Assuming you create symlinks pointing to files with non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts *all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd. I assume this will also happen if you try to create the file with these chars in the first place, so it's not much of a problem. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cygport upload
How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. Thomas
Re: ACL: Why SYSTEM doesn't have full access set on newly created files?
Greetings, Kacper Michajlow! > I know that Cygwin tries to emulate UNIX permissions using ACL. But I don't > understand why SYSTEM doesn't have Full Control allowed or even modify. > Shouldn't generally SYSTEM have access to everything? This is because basic POSIX permissiosn are that -stupid +limited. And because in Windows there's no inherent super-user. Even SYSTEM do not have powers to go against set permissions. POSIX permissions in Cygwin are emulated using Windows ACL. Part of the answer can be found in https://cygwin.com/faq.html#faq.using.ssh-pubkey-stops-working The rest is in https://cygwin.com/cygwin-ug-net/ntsec.html > I have cloned git repository of UWP application, and deployment fails in VS > with error: > "DEP0700: Registration of the app failed. [0x80070005] Deployment Register > operation with target volume F: on Package ... from: (AppxManifest.xml) > failed with error 0x80070005." > It is easily fixable by adding Full Control for SYSTEM on all files, but > that wasn't my first idea, so it took some time :) Long story short, it > fails and might be not obvious for the user why, at the first glance. It is easily fixable by mounting directories outside Cygwin tree with "noacl" flag. It is even required to do so, if you expect interoperation between Cygwin and native tools. > Also when accessing ACL from Explorer it throws: > "The permissions on are incorrectly ordered, which may cause > some entries to be ineffective." > And forces me to reorder them if I want to edit. Don't do that on Cygwin directory tree, you break Cygwin doing this. > That said, I have three questions: > 1. Could Cygwin by default give SYSTEM full control? If not, why? Answered multiple time in the last 20 years. Read the docs. > 2. Could Cygwin put ACL in order, so Windows doesn't complain about it? They are in correct order. Just not canonical order, which Explorer only supports. > 3. Do we need "NULL SID" entry? Yes. > Documentation:https://cygwin.com/docs.html -- With best regards, Andrey Repin Friday, March 27, 2020 12:31:49 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
