[ANNOUNCEMENT] Updated: poco-1.6.0-1
The following packages have been updated in the Cygwin distribution: * libpoco-devel-1.6.0-1 * libpoco-doc-1.6.0-1 * libpoco30-1.6.0-1 * poco-1.6.0-1 The POCO C++ Libraries are open source C++ class libraries that simplify and accelerate the development of network-centric, portable applications in C++. This is an update to the latest upstream release. Note that users of the 'Poco::UTF32String' class should compile using the '-frepo' g++ compiler switch. Details here: https://cygwin.com/ml/cygwin/2015-04/msg00130.html Dave. -- 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
[ANNOUNCEMENT] Updated: icoutils-0.31.0-3
The following package has been updated in the Cygwin distribution: * icoutils-0.31.0-3 The icoutils are a set of programs for extracting and converting images in Microsoft Windows icon and cursor files. This build corrects the perl dependencies, as perl_vendor has been split up, and other perl modules have been renamed. Dave. -- 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
Xemacs 21.5.28-3 No Longer Available
I've been using Xemacs 21.5 because it fixes several problems in version 21.4. I recently had to reinstall Cygwin and found that Xemacs 21.5 is no longer listed. It used to be available in the 32-bit version of Cygwin after clicking on the "Exp" option in the upper right. The exact version was 21.5.28-3. Would it be possible to regain the ability to install this version? Going back to 21.4 is a serious inconvenience. For one thing, Esc-Y (replace Ctrl-Y text with the previous text from the kill ring) is broken. -- 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: Libguile17 dependency issue - attention maintainer
On 4/12/2015 10:39 PM, Eliot Moss wrote: On 4/12/2015 4:17 PM, David Stacey wrote: On 12/04/15 11:03, Marco Atzeri wrote: Seemed to work well with all the '.ly' files I threw at it. I generated PDF, PNG and MIDI files successfully. I tried a few files from a web site with lots of freely available lilypond files, and a couple of files gave warnings. If you try: wget http://www.mutopiaproject.org/ftp/PaganiniN/O1/Caprice_23/Caprice_23.ly lilypond --formats=pdf,png Caprice_23.ly I just built 2.19.18 on 32bit. I received an advise on lilypond devel list, that up to 2.19.15 some bugs were present on 32 bit platform. "make check passes" , so I will test this one also. Then you see repeated instances of the following warnings: warning: no PostScript font name for font `/usr/share/fonts/100dpi/ncenR24.pcf.gz' warning: FreeType face has no PostScript font name I was getting that with the previous version, and segfaults. I had to back up some to get it to work at all, and I recall, I still can't get Times Roman. I wasn't sure who / how to report it, but this thread prompts me to chime in. Struck me as a problem with Guile more than Lilypond itself, but I can't say now why I thought that at the time ... I am taking over also guile. Regards -- Eliot Moss 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-3
On Sun, Apr 12, 2015 at 3:17 PM, Corinna Vinschen wrote: > Hi Cygwin friends and users, > > > New 2.0.0-0.3 test release. It's supposed to fix the pty chmod problem > reported in https://cygwin.com/ml/cygwin/2015-04/msg00240.html > Just a note: In 2.0.0-0.2, creating a file using touch on the root of one of my drives resulted in the with the Windows GUI Security tabs complaining about ACE order on the resultant file. In 2.0.0-0.3, Windows does not complain and the ACL looks quite a bit different (shown below). Not sure if this is a problem or not --- just wanted to report the difference in case your fix had an unintended side affect. Given my heart skips a beat when I see DENY ACEs, I like the new behavior behavior better. V:\>icacls v: v: BUILTIN\Administrators:(OI)(CI)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) NT AUTHORITY\Authenticated Users:(OI)(CI)(M) BUILTIN\Users:(OI)(CI)(RX) Output from file created from 2.0.0-0.3: V:\>icacls touch-from-3 touch-from-3 DOMAIN\Administrator:(R,W,D,WDAC,WO) DOMAIN\Domain Users:(R) Everyone:(R) BUILTIN\Administrators:(F) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\Authenticated Users:(M) BUILTIN\Users:(RX) Successfully processed 1 files; Failed processing 0 files Output from file created from 2.0.0-0.2: V:\>icacls touch-from-2 touch-from-2 NULL SID:(DENY)(Rc,S,WEA,X,DC) DOMAIN\Administrator:(R,W,D,WDAC,WO) DOMAIN\Domain Users:(DENY)(S,X) NT AUTHORITY\Authenticated Users:(DENY)(S,X) BUILTIN\Users:(DENY)(S,X) DOMAIN\Domain Users:(RX) NT AUTHORITY\Authenticated Users:(RX,W) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) BUILTIN\Users:(RX) Everyone:(R) Successfully processed 1 files; Failed processing 0 files -- 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: Libguile17 dependency issue - attention maintainer
On 4/12/2015 4:17 PM, David Stacey wrote: On 12/04/15 11:03, Marco Atzeri wrote: Seemed to work well with all the '.ly' files I threw at it. I generated PDF, PNG and MIDI files successfully. I tried a few files from a web site with lots of freely available lilypond files, and a couple of files gave warnings. If you try: wget http://www.mutopiaproject.org/ftp/PaganiniN/O1/Caprice_23/Caprice_23.ly lilypond --formats=pdf,png Caprice_23.ly Then you see repeated instances of the following warnings: warning: no PostScript font name for font `/usr/share/fonts/100dpi/ncenR24.pcf.gz' warning: FreeType face has no PostScript font name I was getting that with the previous version, and segfaults. I had to back up some to get it to work at all, and I recall, I still can't get Times Roman. I wasn't sure who / how to report it, but this thread prompts me to chime in. Struck me as a problem with Guile more than Lilypond itself, but I can't say now why I thought that at the time ... Regards -- Eliot Moss -- 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: Libguile17 dependency issue - attention maintainer
On 12/04/15 11:03, Marco Atzeri wrote: Removing the cygwin specific usage of cygwin_conv_to_posix_path / cygwin_conv_path did the work. Make check passed on 64bit, and make doc fails on a corner case, most of the HTML documentation was built. OK, so I couldn't resist a little play :-) Seemed to work well with all the '.ly' files I threw at it. I generated PDF, PNG and MIDI files successfully. I tried a few files from a web site with lots of freely available lilypond files, and a couple of files gave warnings. If you try: wget http://www.mutopiaproject.org/ftp/PaganiniN/O1/Caprice_23/Caprice_23.ly lilypond --formats=pdf,png Caprice_23.ly Then you see repeated instances of the following warnings: warning: no PostScript font name for font `/usr/share/fonts/100dpi/ncenR24.pcf.gz' warning: FreeType face has no PostScript font name programming error: Improbable offset for stencil: -inf staff space Setting to zero. continuing, cross fingers I didn't have time to cross my fingers, but the resulting output files all looked fine ;-) I ran the same test using the stock 'lilypond' package in Fedora 21 (the version of lilypond is the same), and the warnings weren't generated. The first warning is a little baffling, as lilypond knows where the PostScript fonts are (the path is specified as a ./configure option). It's worth saying that most of the files I tried worked fine without generating warnings. BTW, I assume you're aware that the 'lilypond-doc' package is missing most of its content, and that this will be fully populated when the 'corner case' you mentioned is ironed out. The 32 bit builds but does not works. I suspect there is an additional problem with the underlying dependencies, or we are triggering an existing problem not visible on Linux platform. Have you tried the old version of lilypond we have in x86 at the moment? I couldn't get it to work at all. Every '.ly' file I passed to it (even simple ones) caused a segmentation fault. So your suspicion about one of the dependencies looks well founded. Dave. -- 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-3
Hi Cygwin friends and users, New 2.0.0-0.3 test release. It's supposed to fix the pty chmod problem reported in https://cygwin.com/ml/cygwin/2015-04/msg00240.html Other than that... The important change in this release is the POSIX permission handling change, a rewrite of the underlying routines reading and creating Windows ACLs following POSIX permission rules and POSIX ACL creating rules per POSIX 1003.1e draft 17, as on Linux. For a description of POSIX ACLs, see http://linux.die.net/man/5/acl All changes in this release so far: === - New, unified implementation of POSIX permission and ACL handling. The new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and they allow to inherit the S_ISGID bit. ACL inheritance now really works as desired, in a limited, but theoretically equivalent fashion even for non-Cygwin processes. To accommodate Windows default ACLs, the new code ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. The new code now handles the S_ISGID bit on directories as on Linux: Setting S_ISGID on a directory causes new files and subdirs created within to inherit its group, rather than the primary group of the user who created the file. This only works for files and directories created by Cygwin processes. - basename(3) now comes in two flavors, POSIX and GNU. The POSIX version is the default. You get the GNU version after #define _GNU_SOURCE #include - The maximum number of PTYs has been raised from 64 to 128. Bug Fixes - - Fix potential hang in pseudo ttys when generating ECHO output while the slave is flooding the pty with output. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00019.html - Fix potential premature SIGHUP in pty code. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00070.html - Fix a name change from symlink to target name in calls to execvp, system, etc. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00270.html - Fix internal error in pty -ONLCR handling. Fix timing bug in pty OPOST handling. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00929.html NOTE: This change introduces a not yet addressed regression. Native Windows tools generating output with Unix LF instead of Windows CRLF line endings will not get OPOST handling. This prominently affects icacls. - Avoid creating passwd and group records from fully qualified Windows account names (domain\name, name@domain). Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00528.html - Avoid potential crash at startup or in getgroups(2). Addresses: https://cygwin.com/ml/cygwin/2015-04/msg00010.html - Fix UTF-16 surrogate handling in wctomb and friends. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00452.html To install 32-bit Cygwin use https://cygwin.com/setup-x86.exe To install 64 bit Cygwin use https://cygwin.com/setup-x86_64.exe If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: Cygwin version numbers [Was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-1]
On Apr 12 16:15, Adam Dinwoodie wrote: > On 11/04/2015 11:35, Corinna Vinschen wrote: > >The version number is 2.0.0-0.1. Yes, we're going full Torvalds with > > the release numbers and bump them to 2.0. In future, bugfix releases > > will bump the last number, new feature releases will bump the middle > > number. > > > > Bugfix? 2.0.1, 2.0.2, ... > > New features? 2.1, 2.2, ... > > Does this mean the version number distinction between the GPL and propriety > versions of the Cygwin DLL are disappearing? There is no propriety version of the Cygwin DLL. The distinction (the idea being about 15 years old) was only for the sake of being able to identify the upstream from the supported version. The supported version will just get an own subversion and a marker, along the lines of "2.0.5rh". > IIRC it's currently the case > that version 1. indicates a closed-source license version, and 1. > indicates a GPL-licensed version. There are no Cygwin versions for which the source code isn't available, While, technically, a third party can purchase a GPL buyout for their own, proprietary product, the Cygwin sources are always freely available. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgplASMMlgCiA.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-2
On Apr 12 16:53, Corinna Vinschen wrote: > On Apr 12 15:31, Achim Gratz wrote: > > > > THere seems to be a bug that causes sshd to be unable to change the new > > PTY to mode "0600" (I'm using privilege separation). > > > > ~ (2001) ll /dev/pty0 ; getfacl /dev /dev/pty0 > > crw--w 1 ASSI Kein 136, 0 12. Apr 15:26 /dev/pty0 > > Hmm, works on the command line... > > $ ll /dev/pty0 > crw--w 1 corinna vinschen 136, 0 Apr 12 16:28 /dev/pty0 > $ chmod 600 !$ > chmod 600 /dev/pty0 > $ ll /dev/pty0 > crw--- 1 corinna vinschen 136, 0 Apr 12 16:28 /dev/pty0 > > ...but I can easily reproduce it from sshd. I'll have a look this week. I think I fixed it. Please try the latest developer snapshot or wait for 2.0.0-0.3. I'm just building. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYHyT6ENhOt.pgp Description: PGP signature
Re: [TESTERS needed] New POSIX permission handling
On 11/04/2015 16:58, Andrey Repin wrote: Greetings, Steven Penny! > >>> What is '~+'? Is that some weird bash feature? > >> If the tilde-prefix is ‘~+’, the value of the shell variable PWD >> replaces the tilde-prefix. > >> http://gnu.org/software/bash/manual/html_node/Tilde-Expansion > > In other words, "~+/" is a weird way to say "./" ? Strictly, no: `echo ./` will print `./`, while `echo ~+/` will print the absolute current path, the same as `echo "$PWD"/` would. -- 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
Cygwin version numbers [Was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-1]
On 11/04/2015 11:35, Corinna Vinschen wrote: The version number is 2.0.0-0.1. Yes, we're going full Torvalds with > the release numbers and bump them to 2.0. In future, bugfix releases > will bump the last number, new feature releases will bump the middle > number. > > Bugfix? 2.0.1, 2.0.2, ... > New features? 2.1, 2.2, ... Does this mean the version number distinction between the GPL and propriety versions of the Cygwin DLL are disappearing? IIRC it's currently the case that version 1. indicates a closed-source license version, and 1. indicates a GPL-licensed version. -- 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
[ANNOUNCEMENT] [Test] maxima-5.36.0-1
This is a new upstream release. I've patched up the build system quite a bit, so I'd welcome feedback from testers. Maxima - Computer Algebra System Maxima is a system for the manipulation of symbolic and numerical expressions, including differentiation, integration, Taylor series, Laplace transforms, ordinary differential equations, systems of linear equations, polynomials, sets, lists, vectors, matrices and tensors. Maxima yields high precision numerical results by using exact fractions, arbitrary-precision integers and variable-precision floating-point numbers. Maxima can plot functions and data in two and three dimensions. Maxima is written in CommonLisp and based on the DOE Macsyma that was developed at MIT. Packaging = The installation has been split into several packages: maxima- common components and documentation, execution on pre-compiled clisp (memory image) maxima-lang-* - localization for several languages maxima-xmaxima- a Tcl/Tk based GUI The maxima-exec-clisp package has been revoked due to problems with the way CLisp creates the executable. Loading a memory image instead has proved to make no difference in start-up time at least on a system with a fast disk, so no disadvantage should result for the user. Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-2
On Apr 12 15:31, Achim Gratz wrote: > > THere seems to be a bug that causes sshd to be unable to change the new > PTY to mode "0600" (I'm using privilege separation). > > ~ (2001) ll /dev/pty0 ; getfacl /dev /dev/pty0 > crw--w 1 ASSI Kein 136, 0 12. Apr 15:26 /dev/pty0 Hmm, works on the command line... $ ll /dev/pty0 crw--w 1 corinna vinschen 136, 0 Apr 12 16:28 /dev/pty0 $ chmod 600 !$ chmod 600 /dev/pty0 $ ll /dev/pty0 crw--- 1 corinna vinschen 136, 0 Apr 12 16:28 /dev/pty0 ...but I can easily reproduce it from sshd. I'll have a look this week. > # file: /dev/pty0 > # owner: ASSI > # group: Kein > user::rw- > group::rw- > other:rw- > > Reverting to the 1.7.35-1 DLL gets sshd working correctly again. > Looking at the above I've questions about the permissions: on Linux the > PTY would be writable by the tty group, but having it writable by "None" > is surely a mistake an getfacl doesn't seem to report anything sensible > on PTY. The acl(2) function is not implemented for ptys. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptflutdrOW1.pgp Description: PGP signature
Re: Cygwin 2.0 (not related to object permissions)
On Apr 12 15:44, Houder wrote: > Hi Corinna, > > Just reporting (can wait until everything related to object permissions have > been solved) > > - Although I am not informed about the internals, I know that (in general), > I can invoke >a 32-bits Cygwin exe from 64-bits Cygwin, and vice versa >Like this: 64-@@ /drv/e/Cygwin/bin/date # invocation from 64-bits Cygwin > > - After creating pristine installations for Cygwin 2.0 (32-bits and > 64-bits), I carried >out the same command >Like this: 64-%% /drv/e/Cygwin-test/bin/date # invocation from 64-bits > Cygwin > > Cygwin 2.0 insert additional white space before the prompt ... (see below). > > Perhaps related to the regression (pty) you mentioned ... Right. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpRC2xxkvgim.pgp Description: PGP signature
Re: [TESTERS needed] New POSIX permission handling
On Apr 12 06:21, İsmail Dönmez wrote: > Hi, > > > Corinna Vinschen-2 wrote > > On Apr 11 10:11, donmez wrote: > >> Hi, > >> > >> > >> Corinna Vinschen-2 wrote > >> > Hi folks, > >> > > >> > > >> > I just applied a patch I'm working on for quite some time now. As I > >> > outlined before on this list, the POSIX permission handling has aged > >> > considerably and, for historical reasons, did things differently > >> > dependent on the calling function. I took the time to reimplement the > >> > core functionality to handle all ACLs as strictly following POSIX ACL > >> > rules as possible. > >> > >> I tested the updated package and at least quilt and mutt seems to broken > >> by > >> the permission changes: > >> > >> [~]> quilt new foo > >> cat: /tmp/quilt.mwTVWM: Permission denied > >> Patch patches/foo is now on top > >> > >> And running mutt results in: > >> > >> "Error creating temporary file /tmp/mutt-" > >> > >> Rolling back to an older snapshot fixes the problem. > > > > Thanks, but... > > > > No offense, but this is not overly helpful. The problem is to learn > > *why* this happens and how to fix it. For that I'd need to know what > > your permissions on /tmp look like (ls -l, getfacl, icacls). Creating > > files in my /tmp (having an old-style ACL) with the following > > permissions works as desired for me: > > Hopefully this will shed some more light: It does, thank you. The problem is the dreaded "owner == group" problem introduced with these weird Microsoft accounts. I completely forgot about this while implementing the new code. It's pretty tricky to get the Windows ACL right for this. Additionally the ACLs already created by setup are... borderline correct only. Back to the drawing board... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpiN3Bd7Vz67.pgp Description: PGP signature
Re: Cygwin 2.0 (not related to object permissions)
> Just reporting (can wait until everything related to object permissions have > been solved) > > - Although I am not informed about the internals, I know that (in general), > I can invoke >a 32-bits Cygwin exe from 64-bits Cygwin, and vice versa >Like this: 64-@@ /drv/e/Cygwin/bin/date # invocation from 64-bits Cygwin > > - After creating pristine installations for Cygwin 2.0 (32-bits and > 64-bits), I carried >out the same command >Like this: 64-%% /drv/e/Cygwin-test/bin/date # invocation from 64-bits > Cygwin > > Cygwin 2.0 insert additional white space before the prompt ... (see below). The output of ls is even worse ... 64-%% /drv/e/Cygwin-test/bin/ls / bin Cygwin.bat Cygwin.ico Cygwin-Terminal.ico dev drv etc home lib MinTTY (test).lnk proc sbin tmp usr var 64-%% Henri = -- 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
Cygwin 2.0 (not related to object permissions)
Hi Corinna, Just reporting (can wait until everything related to object permissions have been solved) - Although I am not informed about the internals, I know that (in general), I can invoke a 32-bits Cygwin exe from 64-bits Cygwin, and vice versa Like this: 64-@@ /drv/e/Cygwin/bin/date # invocation from 64-bits Cygwin - After creating pristine installations for Cygwin 2.0 (32-bits and 64-bits), I carried out the same command Like this: 64-%% /drv/e/Cygwin-test/bin/date # invocation from 64-bits Cygwin Cygwin 2.0 insert additional white space before the prompt ... (see below). Perhaps related to the regression (pty) you mentioned ... Regards, Henri = Cygwin 1.7 @@ uname -a CYGWIN_NT-6.1-WOW Seven 1.7.36(0.287/5/3) 2015-03-17 10:46 i686 Cygwin @@ ls -l /bin/cygwin1* -rwxr-xr-x 1 Henri None 2667071 Mar 18 08:12 /bin/cygwin1.dll -rwxr-xr-x 1 Henri None2295 Feb 12 23:37 /bin/cygwin1.sh -rwxr-xr-x 1 Henri None 3197390 Aug 13 2014 /bin/cygwin1-1.7.32-1.dll -rwxr-xr-x 1 Henri None 3339793 Mar 4 12:08 /bin/cygwin1-1.7.35.dll -rwxr-xr-x 1 Henri None 2667071 Mar 18 08:12 /bin/cygwin1-20150317-x86.dll @@ date Sun Apr 12 15:12:30 CEST 2015 @@ /drv/e/Cygwin64/bin/date Sun Apr 12 15:12:44 CEST 2015 @@ 64-@@ uname -a CYGWIN_NT-6.1 Seven 1.7.36(0.287/5/3) 2015-03-17 10:46 x86_64 Cygwin 64-@@ ls -l /bin/cygwin1* -rwxr-xr-x 1 Henri None 2569781 Mar 18 08:12 /bin/cygwin1.dll -rwxr-xr-x 1 Henri None2102 Nov 25 11:02 /bin/cygwin1.sh -rwxr-xr-x 1 Henri None 3156896 Aug 13 2014 /bin/cygwin1-1.7.32-1.dll -rwxr-xr-x 1 Henri None 3265340 Mar 4 12:09 /bin/cygwin1-1.7.35.dll -rwxr-xr-x 1 Henri None 2569781 Mar 18 08:12 /bin/cygwin1-20150317-x86_64.dll 64-@@ date Sun Apr 12 15:12:10 CEST 2015 64-@@ /drv/e/Cygwin/bin/date Sun Apr 12 15:12:15 CEST 2015 64-@@ = Cygwin 2.0 %% uname -a CYGWIN_NT-6.1-WOW Seven 2.0.0(0.287/5/3) 2015-04-11 16:07 i686 Cygwin %% ls -l /bin/cygwin1* -rwxr-xr-x 1 Henri None 3358408 Apr 11 16:08 /bin/cygwin1.dll %% date Sun, Apr 12, 2015 3:11:13 PM %% /drv/e/Cygwin64-test/bin/date Sun, Apr 12, 2015 3:11:22 PM %% < additional white space %% 64-%% uname -a CYGWIN_NT-6.1 Seven 2.0.0(0.287/5/3) 2015-04-11 16:10 x86_64 Cygwin 64-%% ls -l /bin/cygwin1* -rwxr-xr-x 1 Henri None 3288338 Apr 11 16:10 /bin/cygwin1.dll 64-%% date Sun, Apr 12, 2015 3:10:46 PM 64-%% /drv/e/Cygwin-test/bin/date Sun, Apr 12, 2015 3:10:51 PM 64-%% < additional white space 64-%% = -- 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: Updated: libfakesu 1.1.0
Kelley Cook wrote: On Thu, Apr 2, 2015 at 1:16 PM, Daniel wrote: This library simulates the Unix root user. It is meant to make porting Unix programs to Cygwin easier. Many Unix daemon programs, such as Apache, Sendmail and Procmail, start up as root but change to an unprivileged user ID. By including this library, any Cygwin super-user (member of the 'Administrators' group) will be represented with user id '0' to your program. Hi Daniel, Shouldn't this package be released for cygwin64 also? KC You're right. I will as soon as I get my 64bit machine ready. -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-2
THere seems to be a bug that causes sshd to be unable to change the new PTY to mode "0600" (I'm using privilege separation). ~ (2001) ll /dev/pty0 ; getfacl /dev /dev/pty0 crw--w 1 ASSI Kein 136, 0 12. Apr 15:26 /dev/pty0 # file: /dev # owner: ASSI # group: Kein user::rwx group::--- group:SYSTEM:rwx group:Administratoren:rwx mask:rwx other:--- default:user::rwx default:user:ASSI:rwx default:group::--- default:group:SYSTEM:rwx default:group:Administratoren:rwx default:mask:rwx default:other:--- # file: /dev/pty0 # owner: ASSI # group: Kein user::rw- group::rw- other:rw- Reverting to the 1.7.35-1 DLL gets sshd working correctly again. Looking at the above I've questions about the permissions: on Linux the PTY would be writable by the tty group, but having it writable by "None" is surely a mistake an getfacl doesn't seem to report anything sensible on PTY. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: [TESTERS needed] New POSIX permission handling
Hi, Corinna Vinschen-2 wrote > On Apr 11 10:11, donmez wrote: >> Hi, >> >> >> Corinna Vinschen-2 wrote >> > Hi folks, >> > >> > >> > I just applied a patch I'm working on for quite some time now. As I >> > outlined before on this list, the POSIX permission handling has aged >> > considerably and, for historical reasons, did things differently >> > dependent on the calling function. I took the time to reimplement the >> > core functionality to handle all ACLs as strictly following POSIX ACL >> > rules as possible. >> >> I tested the updated package and at least quilt and mutt seems to broken >> by >> the permission changes: >> >> [~]> quilt new foo >> cat: /tmp/quilt.mwTVWM: Permission denied >> Patch patches/foo is now on top >> >> And running mutt results in: >> >> "Error creating temporary file /tmp/mutt-" >> >> Rolling back to an older snapshot fixes the problem. > > Thanks, but... > > No offense, but this is not overly helpful. The problem is to learn > *why* this happens and how to fix it. For that I'd need to know what > your permissions on /tmp look like (ls -l, getfacl, icacls). Creating > files in my /tmp (having an old-style ACL) with the following > permissions works as desired for me: Hopefully this will shed some more light: [~]> uname -rm 2.0.0(0.287/5/3) x86_64 [~]> ls -ld /tmp drwxrwxrwt+ 1 ismail ismail 0 Apr 12 16:13 /tmp [~]> getfacl /tmp # file: /tmp # owner: ismail # group: ismail # flags: --t user::rwx user:ismail:rwx group::rwx mask:rwx other:rwx default:user::rwx default:group::r-x default:mask:r-x default:other:r-x [~]> icacls C:\\cygwin64\\tmp C:\cygwin64\tmp UX31A\ismail:(F) UX31A\ismail:(RX,W) Everyone:(RX,W) NULL SID:(RD) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files [~]> touch /tmp/foo [~]> ls -l /tmp/foo -rw-r--r--+ 1 ismail ismail 0 Apr 12 16:16 /tmp/foo [~]> getfacl /tmp/foo # file: /tmp/foo # owner: ismail # group: ismail user::rw- user:ismail:r-x group::--- mask:r-- other:r-- [~]> icacls C:\\cygwin64\\tmp\\foo C:\cygwin64\tmp\foo NULL SID:(DENY)(Rc,S,X,DC) UX31A\ismail:(DENY)(S,X) UX31A\ismail:(R,W,D,WDAC,WO) UX31A\ismail:(RX) UX31A\ismail:(DENY)(S,X) UX31A\ismail:(RX) Everyone:(R) Successfully processed 1 files; Failed processing 0 files I hope this to be a generic bug, skimmed over one important details. This is on Win 10 beta build 10049 x64. Thanks! -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117479.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Libguile17 dependency issue - attention maintainer
On 12/04/15 11:03, Marco Atzeri wrote: On 2/21/2015 12:19 AM, David Stacey wrote: On 20/02/15 15:42, Corinna Vinschen wrote: unfortunately it turns out that our guile (and lilypond) maintainer has left us, so the packages are orphaned. Jan's last version of guile was 1.8.7-2 for 32 bit. Does anybody have fun to take over maintainership of guile or lilypond? First, let me say that I have no intention of maintaining lilypond - I am aware that even replying to this e-mail puts me in danger of acquiring another couple of packages ;-) I absolutely love lilypond and would like it to stay within Cygwin if at all possible, but I don't have the time right now to take on a package that is going to be a little problematic. I had a go at building lilypond for x86_64 about 18 months ago, but didn't get very far. I managed to produce an executable, but 'make doc' and 'make check' both failed, so I didn't have any confidence in the binary produced. My need for a working lilypond exceeded the tinkering time available, so I just used Fedora. I've tidied up the cygport file this evening, and this (along with a small patch) is attached. Hopefully this will be a starting point for a prospective maintainer with the time to do it justice. Dave. Thanks Dave, for the starting point. I used that as base for the 64 bit package just released. Removing the cygwin specific usage of cygwin_conv_to_posix_path / cygwin_conv_path did the work. Make check passed on 64bit, and make doc fails on a corner case, most of the HTML documentation was built. Well done - you've already got further than I managed. I have a soft spot for lilypond, so I'm really pleased that you've adopted it - I'd hate to see it removed from Cygwin. Next time I update my 64-bit installation I'll give it a test. Dave. -- 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: Shared memory handling for mixed C/FORTRAN program
On Apr 12 13:23, Corinna Vinschen wrote: > On Apr 11 20:25, Christoph Weise wrote: > > Please see below, I provide minimal C code for three separate > > executables, one creates the shm section, another finds it, the third > > removes it. I include also a bash test script that executes the > > routines in order. > > Thanks, > > > Please beware as I removed some checks to reduce > > the length of the code, but it should run ok. The PAGESIZE parameter > > is hardcoded (here 512 bytes). The desired shared mem section size is > > set interactively as input to makeshm, or automatically with the bash > > script. > > Ok, but there are bugs in the code which result in GCC warnings. I > don't know which of them are part of your original code, but they are > really a problem. > > if ((int) -1 == p) > > Don't check a pointer against an int value. It won't work on a 64 bit > platform. Make that > > if ((void *) -1 == p) > > For the same reason, don't use %x to printf a pointer. Use %tx. > > > I can write to the shm section with the second routine when the requested > > section <= 4096 bytes. Otherwise it's not happy. > > The problem is the call to shmget: > > #undef PAGESIZE > #define PAGESIZE 512 > shmid = shmget(key, PAGESIZE, IPC_ALLOC); > > Since you're requesting only 512 bytes, the shared memory segment the > following shmat call returns is only 4K. The shmget call should request > as much memory as it needs so that the OS call is called with the right > view size. > > I re-read the POSIX man page for shmget, and it doesn't mention anything > which would point out that Cygwin's behaviour here is wrong. If anybody > has more information on this, please share them. On second thought, adjusting Cygwin's behaviour to Linux here is rather trivial. I applied a patch to the git repo and uploaded new developer snapshots (2015-04-12) to https://cygwin.com/snapshots/ You only have to replace the DLL itself, cygserver is not affected by this patch. Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJhVdiV7_zt.pgp Description: PGP signature
Re: Shared memory handling for mixed C/FORTRAN program
On Apr 11 20:25, Christoph Weise wrote: > Please see below, I provide minimal C code for three separate > executables, one creates the shm section, another finds it, the third > removes it. I include also a bash test script that executes the > routines in order. Thanks, > Please beware as I removed some checks to reduce > the length of the code, but it should run ok. The PAGESIZE parameter > is hardcoded (here 512 bytes). The desired shared mem section size is > set interactively as input to makeshm, or automatically with the bash > script. Ok, but there are bugs in the code which result in GCC warnings. I don't know which of them are part of your original code, but they are really a problem. if ((int) -1 == p) Don't check a pointer against an int value. It won't work on a 64 bit platform. Make that if ((void *) -1 == p) For the same reason, don't use %x to printf a pointer. Use %tx. > I can write to the shm section with the second routine when the requested > section <= 4096 bytes. Otherwise it's not happy. The problem is the call to shmget: #undef PAGESIZE #define PAGESIZE 512 shmid = shmget(key, PAGESIZE, IPC_ALLOC); Since you're requesting only 512 bytes, the shared memory segment the following shmat call returns is only 4K. The shmget call should request as much memory as it needs so that the OS call is called with the right view size. I re-read the POSIX man page for shmget, and it doesn't mention anything which would point out that Cygwin's behaviour here is wrong. If anybody has more information on this, please share them. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpZrjnVezZ9G.pgp Description: PGP signature
Re: Libguile17 dependency issue - attention maintainer
On 2/21/2015 12:19 AM, David Stacey wrote: On 20/02/15 15:42, Corinna Vinschen wrote: unfortunately it turns out that our guile (and lilypond) maintainer has left us, so the packages are orphaned. Jan's last version of guile was 1.8.7-2 for 32 bit. Does anybody have fun to take over maintainership of guile or lilypond? First, let me say that I have no intention of maintaining lilypond - I am aware that even replying to this e-mail puts me in danger of acquiring another couple of packages ;-) I absolutely love lilypond and would like it to stay within Cygwin if at all possible, but I don't have the time right now to take on a package that is going to be a little problematic. I had a go at building lilypond for x86_64 about 18 months ago, but didn't get very far. I managed to produce an executable, but 'make doc' and 'make check' both failed, so I didn't have any confidence in the binary produced. My need for a working lilypond exceeded the tinkering time available, so I just used Fedora. I've tidied up the cygport file this evening, and this (along with a small patch) is attached. Hopefully this will be a starting point for a prospective maintainer with the time to do it justice. Dave. Thanks Dave, for the starting point. I used that as base for the 64 bit package just released. Removing the cygwin specific usage of cygwin_conv_to_posix_path / cygwin_conv_path did the work. Make check passed on 64bit, and make doc fails on a corner case, most of the HTML documentation was built. The 32 bit builds but does not works. I suspect there is an additional problem with the underlying dependencies, or we are triggering an existing problem not visible on Linux platform. 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-2
Hi Cygwin friends and users, New 2.0.0-0.2 test release. It just fixes a chmod permission mask typo as described in https://cygwin.com/ml/cygwin/2015-04/msg00206.html and https://cygwin.com/ml/cygwin/2015-04/msg00210.html Other than that... The important change in this release is the POSIX permission handling change, a rewrite of the underlying routines reading and creating Windows ACLs following POSIX permission rules and POSIX ACL creating rules per POSIX 1003.1e draft 17, as on Linux. For a description of POSIX ACLs, see http://linux.die.net/man/5/acl All changes in this release so far: === - New, unified implementation of POSIX permission and ACL handling. The new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and they allow to inherit the S_ISGID bit. ACL inheritance now really works as desired, in a limited, but theoretically equivalent fashion even for non-Cygwin processes. To accommodate Windows default ACLs, the new code ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. The new code now handles the S_ISGID bit on directories as on Linux: Setting S_ISGID on a directory causes new files and subdirs created within to inherit its group, rather than the primary group of the user who created the file. This only works for files and directories created by Cygwin processes. - basename(3) now comes in two flavors, POSIX and GNU. The POSIX version is the default. You get the GNU version after #define _GNU_SOURCE #include - The maximum number of PTYs has been raised from 64 to 128. Bug Fixes - - Fix potential hang in pseudo ttys when generating ECHO output while the slave is flooding the pty with output. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00019.html - Fix potential premature SIGHUP in pty code. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00070.html - Fix a name change from symlink to target name in calls to execvp, system, etc. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00270.html - Fix internal error in pty -ONLCR handling. Fix timing bug in pty OPOST handling. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00929.html NOTE: This change introduces a not yet addressed regression. Native Windows tools generating output with Unix LF instead of Windows CRLF line endings will not get OPOST handling. This prominently affects icacls. - Avoid creating passwd and group records from fully qualified Windows account names (domain\name, name@domain). Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00528.html - Avoid potential crash at startup or in getgroups(2). Addresses: https://cygwin.com/ml/cygwin/2015-04/msg00010.html - Fix UTF-16 surrogate handling in wctomb and friends. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00452.html To install 32-bit Cygwin use https://cygwin.com/setup-x86.exe To install 64 bit Cygwin use https://cygwin.com/setup-x86_64.exe If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: Executable from x86_64-w64-mingw32-gcc.exe waits for input before prompt in Cygwin terminal but not Win Command Prompt
On Apr 11 20:15, Randy Decker wrote:
> # Brief problem description
> # C source file - 'printf("Test");' added as diagnostics
> # Source compiles and executes in Ubuntu
> # Executable compiled in cygwin terminal OK in command prompt W8.1
> # - Also OK in another machine running Windows 8.1
> # Same executable in cygwin term waits for input before usage hint
It's a buffering problem. The Cygwin terminal is using a pty which is
implemented using Named Pipes for stdio descriptors under the hood. The
Windows libraries go into full buffered stdio mode. One workaround is
an explicit call to fflush(stdout) before asking for input.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpITaUtic0cE.pgp
Description: PGP signature
Re: rejected mail to the list
On Apr 11 10:32, Rodrigo Medina wrote: > Hi, > My maail to this list is being reject because: > > Delivery to the following recipient failed permanently: > > cygwin@cygwin.com > > Technical details of permanent failure: > Google tried to deliver your message, but it was rejected by the server for > the recipient domain cygwin.com by sourceware.org. [209.132.180.131]. > > The error that the other server returned was: > 552 spam score exceeded threshold > --- > > How can I solve this problem? Was the mail on symlinks the one which didn't go through originally? If you still have this problem, please ask postmaster AT sourceware DOT org and ideally attach a copy of the rejected posting. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYSHXSOs9VH.pgp Description: PGP signature
Re: [TESTERS needed] New POSIX permission handling
On Apr 11 10:11, donmez wrote: > Hi, > > > Corinna Vinschen-2 wrote > > Hi folks, > > > > > > I just applied a patch I'm working on for quite some time now. As I > > outlined before on this list, the POSIX permission handling has aged > > considerably and, for historical reasons, did things differently > > dependent on the calling function. I took the time to reimplement the > > core functionality to handle all ACLs as strictly following POSIX ACL > > rules as possible. > > I tested the updated package and at least quilt and mutt seems to broken by > the permission changes: > > [~]> quilt new foo > cat: /tmp/quilt.mwTVWM: Permission denied > Patch patches/foo is now on top > > And running mutt results in: > > "Error creating temporary file /tmp/mutt-" > > Rolling back to an older snapshot fixes the problem. Thanks, but... No offense, but this is not overly helpful. The problem is to learn *why* this happens and how to fix it. For that I'd need to know what your permissions on /tmp look like (ls -l, getfacl, icacls). Creating files in my /tmp (having an old-style ACL) with the following permissions works as desired for me: $ uname -rm 2.0.0(0.287/5/3) x86_64 $ ls -ld /tmp drwxrwxrwt+ 1 corinna vinschen 0 Apr 12 10:25 /tmp $ getfacl /tmp # file: /tmp # owner: corinna # group: vinschen # flags: --t user::rwx group::rwx mask:rwx other:rwx default:user::rwx default:group::r-x default:mask:r-x default:other:r-x $ icacls C:\\cygwin64\\tmp C:\cygwin64\tmp VINSCHEN\corinna:(F) VINSCHEN\vinschen:(RX,W) Everyone:(RX,W) NULL SID:(RD) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files $ touch /tmp/foo $ ls -l /tmp/foo -rw-r--r-- 1 corinna vinschen 0 Apr 12 10:25 /tmp/foo $ getfacl /tmp/foo # file: /tmp/foo # owner: corinna # group: vinschen user::rw- group::r-x mask:r-- other:r-- $ icacls C:\\cygwin64\\tmp\\foo C:\cygwin64\tmp\foo NULL SID:(DENY)(Rc,S,X,DC) VINSCHEN\corinna:(R,W,D,WDAC,WO) VINSCHEN\vinschen:(DENY)(S,X) VINSCHEN\vinschen:(RX) Everyone:(R) Successfully processed 1 files; Failed processing 0 files $ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpyGabETkSye.pgp Description: PGP signature
Re: [TESTERS needed] New POSIX permission handling
On Apr 11 09:26, Ernie Rael wrote: > I'm primarily a lurker, reading this list hoping things soak in a bit. So I > may be off base on this. > > In the table below, describing "NULL DENY access mask", looks like there's a > typo concerning read/execute. (of course it might just be a windows mapping > peculiarity that I really didn't want to know about ;-) Hey, cool, somebody noticed :) And since you asked, you'll get to know, whether you want or not ;) > >The following bits in the NULL DENY access mask are used: > > > > Windows access<-> POSIX access > > -- > > FILE_READ_DATA S_ISVTX > > FILE_WRITE_DATA S_ISGID > > FILE_APPEND_DATAS_ISUID > > > > FILE_READ_EAMASK S_IXOTH (POSIX execute perms) > > FILE_WRITE_EA MASK S_IWOTH (POSIX write perms) > > FILE_EXECUTEMASK S_IROTH (POSIX read perms) > > Are read and execute swapped intentionally in the above? Yes, indeed. since the NULL access mask is not needed for actual permission checking by Windows, we can use the bit as they fit our needs. The reason for using them in this order are their bit values. FILE_READ_EA == 0x08 S_IXOTH == 0x01 FILE_WRITE_EA == 0x10 S_IWOTH == 0x02 FILE_EXECUTE == 0x20 S_IROTH == 0x04 To convert from Windows to POSIX and vice versa, a simple shift operation is sufficient. Reordering just to fit the symbolic name would complicate the conversion unnecessarily. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp6uoQoWl4o4.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-1
> It's what we haxxers call "a bug". I made a typo in another function, > copy-pasted the code over to the chmod function, fixed it in the > original function and then forgot to fix it in chmod. [snip] > I just uploaded a new test release 2.0.0-0.2. It's supposed to fix > this bug. Give it a bit of time to hit the mirrors. ... wait ... more waiting ... Confirmed. This bug has gone. (you knew where to look for it, did you not? :-) Many thanks for all your hard work! Regards, Henri -- 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
