Re: [EXTERNAL] Re: svn crashes when connection to server refused
On 2022-01-17 19:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: Subversion seems to have along list of upstream issues can you check if the issue was already noted and solved upstream ? If so I can deploy a new release. Thanks for the suggestion! Looks like 1.14.1 dated Feb 2021 is the latest official release, per their website; and that's what we have in Cygwin. I also tried to check out and build it right from the repository, but there were some issues Once finally built I got an error message that the https:// scheme wasn’t supported. I guess I missed some configuration peculiarities for Cygwin (but also, I noticed that for some reason the source code treats Cygwin as Windows -- particularly how the pathname is assumed to have the drive letters, and that is really baffling -- so I am not exactly sure what was meant by that by the SVN developers). You should normally be able to build from git-cygwin-packages repo for subversion containing cygport, patches, and any other Cygwin files, but the current release has not yet been checked in at: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/subversion.git although you can see from the tree 21 patches were available to apply. So you have to download the source package which will include the current cygport, patches, and any other Cygwin files. It is often a good idea also to look for relevant source patches available in packages' sources from upstream, as well as other distros such as Fedora (closely related to and used by some to build some Cygwin tools, parts of releases, and packages), Debian, MacPorts, and OpenSuSE where available: https://src.fedoraproject.org/rpms/subversion/tree/rawhide https://salsa.debian.org/lts-team/packages/subversion/-/tree/master/debian/patches https://github.com/macports/macports-ports/tree/0a3636ef019083102b8eb19ba230d173a2a37afe/devel/subversion/files https://github.com/bmwiedemann/openSUSE/tree/master/packages/s/subversion [Thanks to those who pointed me to those package sources repos] -- 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. [Data in binary units and prefixes, physical quantities in SI.] -- 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: [ANNOUNCEMENT] xorg-server-21.1.3-1 / recent setups not working on Win8 / winsymlinks:lnk
On 15/01/2022 18:31, Dan Harkless wrote: On 1/15/2022 10:26 AM, Dan Harkless wrote: [...] Forgive me if this is a FAQ (I tried searching), but is there a standard timeframe in between when a package update is announced on the list and when it's actually available on the mirrors? We have no direct control over how often mirrors choose to sync. However, as is mentioned at the bottom of https://cygwin.com/mirrors.html, we drop a mirror from that list if it isn't up to date for more than 24 hours. (In actual fact, that unduly punishes some mirrors which sync indirectly, so the actual criteria for keeping a mirror on that page is something which approximates "not more than 24 hours out of date for more than 24 hours"). So, mirrors having updated packages within 24 hours is reasonable as a general expectation. Most mirrors are significantly faster, but a few may be a bit slower. I tried every https mirror, but none of them have the new versions. I've been having trouble with the X server and xwin-xdg-menu failing to start up properly (in a semi-non-repeatable way), so I was hoping to get this update now. I tried upgrading setup-x86_64.exe to 2.915, in case some fix was needed to get the new packages to show up, but like the last several versions of the setup programs (2.909 is the last one I remember working), it doesn't work on my Windows 8.1 system (with all available MS updates). Running the installer from Explorer results in nothing happening whatsoever. Running setup from bash as Administrator results in: Starting cygwin install, version 2.915 User has backup/restore rights User has symlink creation right *** --symlink-type lnk is not implemented I've had my CYGWIN environment variable set to "wincmdln winsymlinks:lnk" for ages, and it's always worked before. I /highly/ prefer the lnk implementation of symlinks, since it allows me to make them from non-Admin shells, etc. Oops! That's not how that's intended to work, at all. Thanks for reporting that. I've uploaded setup 2.916 with an attempted fix. https://cygwin.com/setup/setup-2.916.x86_64.exe https://cygwin.com/setup/setup-2.916.x86.exe Please try that, and see if it improves things for you? Oh, and forgot to mention I took a look at https://cygwin.com/mirrors-report.html, and it claims (by omission) that most of the mirrors I tried are supposed to be complete and up-to-date, so... I'm not sure what that page is even indicating. That page is only updated periodically (every 3 hours currently), so if the 'Last updated' time on that page is prior to the change of interest, that page has no information you can use to determine if a mirror has that change or not. -- 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: [ANNOUNCEMENT] xorg-server-21.1.3-1 / recent setups not working on Win8 / winsymlinks:lnk
On 15/01/2022 22:13, Brian Inglis wrote:
On 2022-01-15 12:06, Marco Atzeri wrote:
In this moment however I see on my preferred server that
21.1.3-1 is marked as test.
Jon,
is it intentional ?
I see 21.1.3-1 as current and 21.1.0-1 as test on my local mirror
$mirror/x86_64/setup.{bz2,ini,xz,zst}
and also the master
{ftp,http,https}://cygwin.com/pub/cygwin/x86{,64}/setup.{bz2,ini,xz,zst}
The 21.1.3-1 package was uploaded as 'test', and I then removed the test
flag after doing some more ... um... testing.
--
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: [EXTERNAL] Re: svn crashes when connection to server refused
On 2022-01-17 23:15, Marco Atzeri wrote: On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Subversion seems to have along list of upstream issues can you check if the issue was already noted and solved upstream ? If so I can deploy a new release. Looks like 1.14.1 dated Feb 2021 is the latest official release, per their website; and that's what we have in Cygwin. I also tried to check out and build it right from the repository, but there were some issues Once finally built I got an error message that the https:// scheme wasn’t supported. I guess I missed some configuration peculiarities for Cygwin (but also, I noticed that for some reason the source code treats Cygwin as Windows -- particularly how the pathname is assumed to have the drive letters, and that is really baffling -- so I am not exactly sure what was meant by that by the SVN developers). you can rebuild with the same Cygwin setting and patches reusing the content of the cygwin source packages. You can use Setup to download it. It should appear under /usr/src. You will need to install the package cygport to replicate the build There is large manual to understand the script settings in usr/share/doc/cygport/html/manual/toc_index.html Submitted details for adding Cygwin packages to the Apache Subversion Binary Packages web page: https://subversion.apache.org/packages.html to the Subversion ML: https://lists.apache.org/list?us...@subversion.apache.org:2022-1 Also noticed that current subversion cygport, patches, etc. are not yet checked in to the git-cygwin-packages repo: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/subversion.git;a=summary -- 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. [Data in binary units and prefixes, physical quantities in SI.] -- 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: [EXTERNAL] Re: svn crashes when connection to server refused
On 18.01.2022 18:31, Brian Inglis wrote: On 2022-01-17 23:15, Marco Atzeri wrote: On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Submitted details for adding Cygwin packages to the Apache Subversion Binary Packages web page: https://subversion.apache.org/packages.html to the Subversion ML: https://lists.apache.org/list?us...@subversion.apache.org:2022-1 Also noticed that current subversion cygport, patches, etc. are not yet checked in to the git-cygwin-packages repo: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/subversion.git;a=summary Now they are in sync. Uploading to git repository is always one of the things to do later ... Regards Marco -- 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
permissions problems with files on samba share
Hi ... It is 2022 and there are still people out in the wild running 1.7. They don't want to but had to and are now on the way to cygwin 3.3.3. It was a hard long way, but we are nearly there now. But only nearly. There are some problems left. One of it is user mapping between samba/linux users to windows/cygwin users. All our homeaccounts reside on a linux server running samba. The samba is not running in AD mode, but in traditional domain mode and is backed by a quite big LDAP. We are always logged in with our domain accounts. Now I try to seek help here as I already have spent hell a lot of time on this. Up to now we still run cygwin 1.7.35 and are going now to 3.3.3 (64bit). The new cygwin runs on windows 10/11 together with the old cygwin 1.7 (seperated from each other - not running the same time) on the same machine for testing. We can read files from the homeaccounts without problem, but writting/deleting files is not that easy from the new cygwin. With the old cygwin 1.7 everything is still fine - in this regard. With cygwin 1.7 we had /etc/passwd and /etc/groups in place. With 3.3.3 we use /etc/nsswitch.conf. Creating /etc/passwd on the new 3.3.3 did not change a thing. The CYGWIN envvar is empty on both installs. View of a sample folder in my homeaccount (~/test): native linux: # ls -al ~/test total 36 drwxrwxr-x+ 2 roland develop 4096 Jan 18 20:16 . drwxr-xr-x 84 roland develop 20480 Jan 18 20:17 .. -rw-rwxr--+ 1 roland develop 5 Jan 14 12:27 some_file cygwin 1.7.35 $ls -al ~/test total 1024 drwxr-xr-x 1 roland develop 0 Jan 18 20:16 . drwxr-xr-x 1 roland develop 0 Jan 18 20:17 .. -rwxr-xr-x 1 roland develop 5 Jan 14 12:27 some_file slightly different permissions for some_file but ok so far. cygwin 3.3.3 $ls -al ~/test total 1024 drwxr-xr-x+ 1 Unix_User+1000 Unix_Group+1001 0 Jan 18 20:16 . drwxr-xr-x+ 1 Unix_User+1000 Unix_Group+1001 0 Jan 18 20:17 .. -rw-r--r-- 1 Unix_User+1000 Unix_Group+1001 5 Jan 14 12:27 some_file permissions are different again and owners/groups are different at all! This also has effects on fileprocessing in cygwin. I know this behaviour from old cygwin with no /etc/passwd in place. Here is the /etc/nsswitch.conf from 3.3.3: # /etc/nsswitch.conf # #This file is read once by the first process in a Cygwin process tree. #To pick up changes, restart all Cygwin processes. For a description #see https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch # # Defaults: passwd: files db group:files db #db_enum: cache builtin db_enum: cache builtin local primary db_home: /%H db_shell: /bin/bash db_gecos: windows getent passwd on 3.3.3: $getent passwd roland:*:1049576:1049577:Roland Schwingel,U-ONEVISION\roland,S-1-5-21-123-456-789-1000://subnet-homes/User/roland:/bin/bash SYSTEM:*:18:18:U-NT AUTHORITY\SYSTEM,S-1-5-18:/home/SYSTEM:/bin/bash SYSTEM:*:18:18:U-NT AUTHORITY\SYSTEM,S-1-5-18:/home/SYSTEM:/bin/bash LOCAL SERVICE:*:19:19:U-NT AUTHORITY\LOCAL SERVICE,S-1-5-19:/:/sbin/nologin NETWORK SERVICE:*:20:20:U-NT AUTHORITY\NETWORK SERVICE,S-1-5-20:/:/sbin/nologin Administrators:*:544:544:U-BUILTIN\Administrators,S-1-5-32-544:/:/sbin/nologin NT SERVICE+TrustedInstaller:*:328384:328384:U-NT SERVICE\TrustedInstaller,S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464:/:/sbin/nologin DEVRYZEN-02+Administrator:*:197108:197121:U-DEVRYZEN-02\Administrator,S-1-5-21-3089862167-1060948595-489759208-500:/vol/c/Users/Administrator:/bin/bash DEVRYZEN-02+DefaultAccount:*:197111:197121:U-DEVRYZEN-02\DefaultAccount,S-1-5-21-3089862167-1060948595-489759208-503:/:/bin/bash DEVRYZEN-02+Guest:*:197109:197121:U-DEVRYZEN-02\Guest,S-1-5-21-3089862167-1060948595-489759208-501:/:/bin/bash DEVRYZEN-02+IT:*:197609:197121:IT department,U-DEVRYZEN-02\IT,S-1-5-21-3089862167-1060948595-489759208-1001:/vol/c/Users/IT:/bin/bash DEVRYZEN-02+me:*:197610:197121:Test user,U-DEVRYZEN-02\me,S-1-5-21-3089862167-1060948595-489759208-1002:/vol/c/Users/me:/bin/bash DEVRYZEN-02+WDAGUtilityAccount:*:197112:197121:U-DEVRYZEN-02\WDAGUtilityAccount,S-1-5-21-3089862167-1060948595-489759208-504:/:/bin/bash My account on 1.7.35 in /etc/passwd: roland:unused:11000:11001:Roland Schwingel,U-ONEVISION\roland,S-1-5-21-123-456-789-1000://subnet-homes/User/roland:/bin/bash cygwin 3.3.3: mkpasswd -b -l my-pdc | grep roland: roland:*:4244636648:4244636649:Roland Schwingel,U-ONEVISION\roland,S-1-5-21-123-456-789-1000://subnet-homes/User/roland:/bin/bash Putting the /etc/passwd from 1.7.35 in 3.3.3 did not help at all. As you can see the uid/gids are different for the 2 versions for the same user. What am I doing wrong here? I need to access the files on the sambashares like in 1.7. I also observed that listing files on the samba shares is notably slower on 3.3.3 compared to 1.7.35. I tested this a couple of times: time ls -al ~/ >/dev/null is about 0.2 seconds in 1.7 and about 1 second in 3.3. Maybe this is related to the permission pr
Re: python-numpy (1.22.0-1) can't be imported
On 14.01.2022 03:04, airplanemath via Cygwin wrote: On Wed, Jan 12 2022, Marco Atzeri wrote: On 12.01.2022 12:47, ggl329 wrote: Hi Marco, I upgraded python39-numpy to 1.22.0-1, and failed to import numpy. It seems that mtrand.cpython-39-x86_64-cygwin.dll does not have PyInit_mtrand. Could you check if numpy can be imported in your environment? working on it. In theory I have not changed the build between the two versions but there was a patch in 1.19.4-1 for similar issue. Regards Marco I have the same problems with the distribution NumPy package, but I can use a locally-compiled NumPy with no patches. It doesn't look like your build has any patches either: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fpython-numpy-src%2Fpython-numpy-1.22.0-1-src&grep=numpy so that's fun. Out of curiousity, what options are you passing for cpu-baseline and cpu-dispatch? https://numpy.org/devdocs/reference/simd/build-options.html I don't see the newest cygport in the Cygwin package repository. I have not found the root cause yet. As the 1.21.4-1 imports correctly I removed the 1.22.0-1 until I solve the issue. I do not see anything obvious in upstream source between 1.21.4 and 1.22.0 that gives me any hint on root cause. Also 1.22.1 shows the same problem. I excluded the build chain as rebuilding 1.19.4 worked fine for all 3.6 to 3.9 Regards Marco -- 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: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified
On 1/17/2022 1:29 PM, Ken Whitesell wrote: Problem: When moving an XTerm window from the primary display to the second monitor, characters typed into that window are "clipped" at the top. Only about the bottom 75% is drawn. No lower-case letters taller than the "half-height" letters render properly. (Letters such as "a", "c", "m", "n", etc are all rendered correctly. All capital letters and tall lower-case letters (e.g. "b" and "d") have the top quarter clipped off. Additionally the XTerm window shows thin black bars on the right side of the window and along the bottom of the window. The bash prompt and most all characters displayed as the result of the output of a command all display correctly - this is *primarily* affecting characters being typed, and before the "enter" key is pressed. (There is one special case regarding displayed characters. If a program is creating a full screen of output, such as "man", the top line of the screen is clipped.) If the window is in the primary display when the characters are typed, and then the window is moved to the second monitor, the previously-typed characters remain correctly formed, and only new characters typed while the window is in the second monitor are clipped. Environment: The primary display is the laptop's built-in display (1920x1080, 17"). The second monitor is a 27" also at 1920x1080. Operating system is Windows 10, with all current patches and updates. (Ver reports Microsoft Windows [Version 10.0.19044.1466]). XWin server is being started with this command line: E:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec /usr/bin/startxwin -- -listen tcp" Additional info: This appears to be related to using the display "Scaling" option, where the laptop's display is set at 125% and the external monitor's display is set at 100%. If I set both displays the same - either both at 100% _or_ both at 125%, the problem does not appear. If I change the scaling from 125% to 100% on the laptop's display, the problem appears until I restart Cygwin/X. Restarting Cygwin/X shows it displaying properly, until I change the scaling again. Note: XTerm is _not_ the only program that exhibits this behavior. This is consistent among all applications tried, including geany, hexedit, mate-terminal, and lxterminal. (The visual behavior is slightly different for "full screen" application such as geany and hexedit, but it's still apparent that some clipping is occurring with characters being typed.) Other version information: Cygwin setup version 2.915, packages showing as up-to-date include xterm 370-1, xinit 1.4.1-1, xorg-server 21.1.3-1, xorg-x11-fonts-* 7.5-4. (Unsure what other information may be useful.) I've tried searching the message archives, going back through 2018 and have not seen anything that appears relevant. Other searches haven't proved useful, other than indicating that I should try applications other than XTerm. I have tried various settings in different locations, including specifying "-resize=none" and/or -screen options for both monitors. No changes have been made to system.XWinrc. /etc/X11/xinit/startxwinrc has the following lines added before the line "exec /usr/bin/xwin-xdg-menu" line at the bottom of the file: /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & There is no .startxwinrc file in $HOME. I will gladly provide any additional information that may help. Is there a known solution for this? (Or is it known that there is no solution?) Any guidance, pointers, suggestions of avenues for further research, or other information, will all be greatly appreciated. After more research and experimentation, it appears to be related to one of xorg-server, xorg-server-common, or xorg-server-xorg. Installing the older version 1.20.12-1 of these packages allows the windows to be moved between monitors without any issues. Upgrading to the current version 21.1.3-1 creates the problems. I'm able to replicate this behavior on two different laptops with two different external monitors. -- 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
g++ missing stddef.h
g++ (GCC) 10.2.0
Win 7-64
Netbeans 12.5
g++ reported a compiler error in not finding stddef.h referenced in
stdlib.h. I've looked in /usr/include and /usr/include/c++/v1. I found
an stddef.h in /usr/include/c++/v1. Should I copy this to /usr/include?
The command being executed is 'c:\cygwin64\bin\g++.exe -std=c++11 -g -c
NewCFile.cpp -o /dev/null'
I've checked my cygwin setup download options and have all of gcc
modules included for C/C++. This is such an odd error that I feel I'm
missing something, and I'm doing something wrong. Can someone help me
fix this?
thanks
art
= code =
#include /* exit, EXIT_FAILURE */
int main(int argc, char* argv[]) {
exit (1);
}
--
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: Duplicate ACLs? - Can't copy file even with Admin permissions
On Jan 04:14 Corinna Vinschen wrote: > On Jan 10 14:46, Corinna Vinschen wrote: > > On Jan 10 11:07, Corinna Vinschen wrote: > > > On Jan 7 15:56, cyg...@kosowsky.org wrote: > > > > > Corinna Vinschen wrote: > > > > > On Jan 6 16:11, cyg...@kosowsky.org wrote: > > > > > It is. I realized belatedly, that 3da9e136.acl is apparently a > > > > > directory, not a file. > > > > > > > > It's actually a file... > > > > > > This is weird. The meaning of the OI and CI markers are "Object > > > inheritance" and "Container inheritance". These bits only make sense > > > for directories and they control how ACEs are inherited by child objects > > > (files) and child containers (subdirs). > > > [...] > > > I'll have a look into the sources later, but I sure would prefer if > > > I could create such a file locally. > > > > I tried to create a file with equivalent ACL including the inheritence > > flags on W7, W10 and W11, but to no avail. > > Success! I hacked a Q&D application which opens a file, reads its > security descriptor (SD) and just adds the object and container inherit > flags to all its DACL' ACEs and writes the SD back. Albeit Windows > tools and some of the security functions under the hood don't allow to > add inherit flags to files, some functions just write the SD verbatim > without checking. > > So I was finally able to reproduce your issue: > > $ ./hackup acltest > $ icacls acltest > acltest NT AUTHORITY\SYSTEM:(OI)(CI)(F) > Everyone:(OI)(CI)(RX) > BUILTIN\Administrators:(OI)(CI)(F) > > Successfully processed 1 files; Failed processing 0 files > $ getfacl acltest > # file: acltest > # owner: Administrators > # group: SYSTEM > user::rwx > group::rwx > other::r-x > user::rwx > group::rwx > group:SYSTEM:rwx > mask::rwx > other::r-x > > The Cygwin DLL reads the DACL and converts it to a POSIX ACL. An ACE > with inherit flags set is converted to a POSIX access ACE and > additionally to a POSIX default ACE. The latter is done independently > of the file type. The calling function (still in Cygwin) doesn't expect > default ACEs for files and treats them as access ACEs. That's what > you see in the getfacl output above. > > I fixed this in Cygwin by ignoring inheritance flags unless the object > is a directory, so the core function in Cygwin only creates default > ACEs for directories. The result when calling getfacl on such a file > is thus: > > $ getfacl acltest > # file: acltest > # owner: Administrators > # group: SYSTEM > user::rwx > group::rwx > other::r-x > > I uploaded a developer snapshot to https://cygwin.com/snapshots > Please give it a try. > Sorry but I was on vacation last week and didn't have a chance to try the new cygwin dll until now. Indeed, the new cygwin.dll does allow me to copy the files and it does preserve the 'getfacl' (POSIX) acl's (as above). However, it does *not* preserve the full ACL's as reported by 'icacls'. #cp -a 3da9e136.rbf temp #getfacl temp # file: temp # owner: Administrators # group: SYSTEM user::rwx group::rwx other::r-x #icacls 3da9e136.rbf 3da9e136.rbf NT AUTHORITY\SYSTEM:(OI)(CI)(F) Everyone:(OI)(CI)(RX) BUILTIN\Administrators:(OI)(CI)(F) #icacls temp temp BUILTIN\Administrators:(F) NT AUTHORITY\SYSTEM:(RX,W) Everyone:(RX) Similarly, #icacls 3da9e136.rbf /save/ 3da9e136.acl #icacls temp /save temp.acl #cat 3da9e136.acl 3da9e136.rbf D:P(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;WD)(A;OICI;FA;;;BA #cat temp.acl temp D:P(A;;FA;;;BA)(A;;0x1201bf;;;SY)(A;;0x1200a9;;;WD) So, the full Windows ACLs as indicated by 'icacls' differ. Is this the expected behavior??? If so, why??? Interestingly, the windows 'xcopy' command (using the /X or /O flags) doesn't copy the full ACLs correctly either C:\Config.Msi>xcopy /X 3da9e136.rbf temp2 #icacls temp2 temp3 NT AUTHORITY\SYSTEM:(F) Everyone:(RX) BUILTIN\Administrators:(F) #icacls temp2 /save temp2.acl #cat temp2.acl D:PAI(A;;FA;;;SY)(A;;0x1200a9;;;WD)(A;;FA;;;BA) #getfacl temp2 # file: temp2 # owner: Administrators # group: SYSTEM user::rwx group::rwx other::r-x Even using Powershell, I am not able to copy the ACLs exactly: PS C:\CONFIG.MSI> Copy-Item .\3da9e136.rbf temp3 PS C:\CONFIG.MSI> Get-Acl .\3da9e136.rbf | Set-Acl temp3 #icacls.exe temp3 temp6 Everyone:(RX) NT AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F) #icacls temp3 /save temp3.acl #cat temp3.acl temp6 D:PAI(A;;0x1200a9;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)S:PAINO_ACCESS_CONTROL #getfacl temp3 # file: temp3 # owner: Administrators # group: SYSTEM user::rwx group::rwx other::r-x Really not sure what is going on here... and
Re: g++ missing stddef.h
On 19.01.2022 02:06, slipbits wrote:
g++ (GCC) 10.2.0
Win 7-64
Netbeans 12.5
g++ reported a compiler error in not finding stddef.h referenced in
stdlib.h. I've looked in /usr/include and /usr/include/c++/v1. I found
an stddef.h in /usr/include/c++/v1. Should I copy this to /usr/include?
The command being executed is 'c:\cygwin64\bin\g++.exe -std=c++11 -g -c
NewCFile.cpp -o /dev/null'
I've checked my cygwin setup download options and have all of gcc
modules included for C/C++. This is such an odd error that I feel I'm
missing something, and I'm doing something wrong. Can someone help me
fix this?
thanks
art
= code =
#include /* exit, EXIT_FAILURE */
int main(int argc, char* argv[]) {
exit (1);
}
This works for me from CLI
g++ -Wall prova.cc -o prova
So how are you setting your NetBeans ?
g++ --version
g++ (GCC) 11.2.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
