Re: SMBFS mount's file cannot be made executable
On Mon, 18 Nov 2024 17:26:12 +0100
Corinna Vinschen wrote:
> On Nov 16 00:21, Takashi Yano via Cygwin wrote:
> > I built a test program, whose important part is:
> >
> > AUTHZ_RESOURCE_MANAGER_HANDLE hManager = NULL;
> > AUTHZ_CLIENT_CONTEXT_HANDLE hClient = NULL;
> > AUTHZ_ACCESS_REQUEST AccessRequest = {0};
> > AUTHZ_ACCESS_REPLY AccessReply = {0};
> >
> > AUTHZ_RPC_INIT_INFO_CLIENT authzRpcInitInfoClient = {0};
> >
> > WCHAR ObjectUuid[] = L"9a81c2bd-a525-471d-a4ed-49907c0b23da";
> > WCHAR ProtSeq[] = L"ncacn_ip_tcp";
> > WCHAR NetworkAddr[] = L"localhost";
> > WCHAR Endpoint[] = L"135";
> >
> > authzRpcInitInfoClient.version = AUTHZ_INIT_INFO_VERSION_V1;
> > authzRpcInitInfoClient.ObjectUuid = ObjectUuid;
> > authzRpcInitInfoClient.ProtSeq = ProtSeq;
> > authzRpcInitInfoClient.NetworkAddr = NetworkAddr;
> > authzRpcInitInfoClient.Endpoint = Endpoint;
> >
> > AuthzInitializeRemoteResourceManager (&authzRpcInitInfoClient, &hManager);
> >
> > char buf[1024];
> > PTOKEN_USER pTokenUser = (PTOKEN_USER) buf;
> > DWORD len;
> >
> > GetTokenInformation(hToken, TokenUser, pTokenUser, 1024, &len);
> >
> > LUID luid = {0,};
> > AuthzInitializeContextFromSid(0, pTokenUser->User.Sid, hManager,
> > NULL, luid, NULL, &hClient);
> >
> >
> > This test code fails at AuthzInitializeContextFromSid() with
> > RPC_S_UNKNOWN_IF. If AuthzInitializeRemoteResourceManager()
> > is replaced with AuthzInitializeResourceManager(), the error
> > does not occur.
> >
> > I searched the combination of AuthzInitializeContextFromSid()
> > and RPC_S_UNKNOWN_IF, however nothing was found.
>
> RPC_S_UNKNOWN_IF means "unknown interface". I assume this error has
> nothing to do with AuthzInitializeContextFromSid(), but with the
> AuthzInitializeRemoteResourceManager() call.
>
> What I failed, though, is to find a working example for
> AuthzInitializeRemoteResourceManager().
>
> > Any suggestion would be appreciated.
>
> As I said in my previous posting, maybe we don't really need
> AuthzInitializeRemoteResourceManager().
>
> We can safely assume that the current user is already authorized on the
> SMB server. So... shouldn't AuthzInitializeResourceManager be
> sufficient and the code from class authz_ctx already does what we want?
> We may just have to use in in place of calling NtCheckAccess(),
> maybe with a tweak or two...
I already tried AuthzInitializeResourceManager(), but the result
was the same with current implementation...
BTW, I come up with another implementation. This make the things
much simpler. What do you think of the patch attached?
--
Takashi Yano
diff --git a/winsup/cygwin/sec/base.cc b/winsup/cygwin/sec/base.cc
index d5e39d281..c460fecc4 100644
--- a/winsup/cygwin/sec/base.cc
+++ b/winsup/cygwin/sec/base.cc
@@ -28,10 +28,6 @@ details. */
| GROUP_SECURITY_INFORMATION \
| OWNER_SECURITY_INFORMATION)
-static GENERIC_MAPPING NO_COPY_RO file_mapping = { FILE_GENERIC_READ,
- FILE_GENERIC_WRITE,
- FILE_GENERIC_EXECUTE,
- FILE_ALL_ACCESS };
LONG
get_file_sd (HANDLE fh, path_conv &pc, security_descriptor &sd,
bool justcreated)
@@ -608,95 +604,6 @@ check_access (security_descriptor &sd, GENERIC_MAPPING
&mapping,
return ret;
}
-/* Samba override. Check security descriptor for Samba UNIX user and group
- accounts and check if we have an RFC 2307 mapping to a Windows account.
- Create a new security descriptor with all of the UNIX accounts with
- valid mapping replaced with their Windows counterpart. */
-static void
-convert_samba_sd (security_descriptor &sd_ret)
-{
- NTSTATUS status;
- BOOLEAN dummy;
- PSID sid;
- cygsid owner;
- cygsid group;
- SECURITY_DESCRIPTOR sd;
- cyg_ldap cldap;
- tmp_pathbuf tp;
- PACL acl, oacl;
- size_t acl_len;
- PACCESS_ALLOWED_ACE ace;
-
- if (!NT_SUCCESS (RtlGetOwnerSecurityDescriptor (sd_ret, &sid, &dummy)))
-return;
- owner = sid;
- if (!NT_SUCCESS (RtlGetGroupSecurityDescriptor (sd_ret, &sid, &dummy)))
-return;
- group = sid;
-
- if (sid_id_auth (owner) == 22)
-{
- struct passwd *pwd;
- uid_t uid = owner.get_uid (&cldap);
- if (uid < UNIX_POSIX_OFFSET && (pwd = internal_getpwuid (uid)))
- owner.getfrompw (pwd);
-}
- if (sid_id_auth (group) == 22)
-{
- struct group *grp;
-
Re: Thread memory allocation issue
> Given that the result of the investigation a couple years ago was, > essentially, no change to Cygwin's malloc*, why has the problem > manifested again recently? Have you been benchmarking/testing all > along? Can you be more specific about which recent Cygwin versions? The original executable with patches was compiled around 2021 using Cygwin the current GCC and Cygwin at that time. This version does work without problems. There have been several changes to Cygwin after that time so I decided compiling bwa using current Cygwin (3.5.4) to see if it would work without patching and I found that it did not. I compiled a patched version (GCC versions 12.0 - 15.0) and noticed that it did not work either. I then tested the 2021 compiled version and noticed that executable still works. >> Steps to Reproduce >> >> 1. Compile BWA normally >> >> https://github.com/lh3/bwa/ > > What's involved with that? Clone the repo, ./configure, make? Anything else? git clone https://github.com/lh3/bwa/ cd bwa make >> 2. Compile BWA with rpmalloc and the following patch: >> >> >> // In thread worker function: >> #ifdef __CYGWIN__ >> rpmalloc_thread_initialize(); >> #endif >> >> >> // ... thread work ... >> #ifdef __CYGWIN__ >> rpmalloc_thread_finalize(1); >> #endif > Where does that patch go? Assume I know nothing about BWA. These two files are patched: https://github.com/WGSExtract/bwa/blob/cygwin/main.c https://github.com/WGSExtract/bwa/blob/cygwin/kthread.c > Are these examples of runs one would do "in production"? Or are you > running much longer-lasting processing in the usual case? Normal production samples are usually gigabytes in size whereas the testcase has a sample that is only around 20 megabytes but even with a small sample like this it is possible to benchmark the problem. So a production sample of human DNA that might be 60 gigabytes in size and would take Linux version of bwa about three hours would take 24 hours or more on an unpatched bwa on Cygwin. >> 1. The default malloc implementation shows extremely high system time >> (11.265s) compared to the rpmalloc version (0.327s) >> 2. Total real time is about 4.5x slower with default malloc >> 3. The dramatic difference in system time suggests heavy contention in the >> memory allocation subsystem >> 4. The issue only manifests on Cygwin with bwa; the same code performs >> normally on native Linux and MacOS > > Are you saying there is non-bwa code that runs on Cygwin comparably to > Linux and Mac? I think most code runs nearly as fast on Cygwin as it does on Linux, assuming the code does not heavily rely on disk I/O. >> 5. The issue manifests with recent versions of Cygwin but does work with >> older versions > > Again, it would really help if you could give Cygwin versions or at > least dates here... The patch for Cygwin version was committed Mar 28, 2021. > I'll glance at this stuff when I can but I hope to have some answers to > my questions above from you to save me some time. Thank you! I know that there are only a handful of people using bwa on Cygwin but I would guess that this is a good test case to learn something about Cygwin's malloc. Regards, Teemu Nätkinniemi -- 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: Thread memory allocation issue
Hello Teepean, On 11/17/2024 11:32 AM, Teepean via Cygwin wrote: I raised this issue couple of years ago on cygwin-developer but now when the problem has manifested again with recent versions of Cygwin I decided to post this to general discussion list. This (main Cygwin) list is the correct place for reports like this. There is no need to contact me (or other maintainers/devs) off-list. Given that the result of the investigation a couple years ago was, essentially, no change to Cygwin's malloc*, why has the problem manifested again recently? Have you been benchmarking/testing all along? Can you be more specific about which recent Cygwin versions? *My own benchmark, building the Cygwin tree, showed that there wasn't much difference between the half-dozen malloc implementations I tried and they were all spending more time in Windows' ntdll.dll than the current Cygwin malloc (==dlmalloc), though a little less time in Cygwin itself. Steps to Reproduce 1. Compile BWA normally https://github.com/lh3/bwa/ What's involved with that? Clone the repo, ./configure, make? Anything else? 2. Compile BWA with rpmalloc and the following patch: // In thread worker function: #ifdef __CYGWIN__ rpmalloc_thread_initialize(); #endif // ... thread work ... #ifdef __CYGWIN__ rpmalloc_thread_finalize(1); #endif Where does that patch go? Assume I know nothing about BWA. 3. Run both versions with the following command: time ./bwa mem -t 11 chr19_KI270866v1_alt.fasta test_1.fastq test_2.fastq > testorigsingle.sam Without Patch (Default malloc): [M::mem_process_seqs] Processed 12 reads in 30.296 CPU sec, 3.743 real sec [main] Real time: 3.883 sec; CPU: 30.436 sec real 0m3.907s user 0m19.186s sys 0m11.265s With Patch (rpmalloc): [M::mem_process_seqs] Processed 12 reads in 7.530 CPU sec, 0.702 real sec [main] Real time: 0.830 sec; CPU: 7.640 sec real 0m0.868s user 0m7.343s sys 0m0.327s Are these examples of runs one would do "in production"? Or are you running much longer-lasting processing in the usual case? Analysis 1. The default malloc implementation shows extremely high system time (11.265s) compared to the rpmalloc version (0.327s) 2. Total real time is about 4.5x slower with default malloc 3. The dramatic difference in system time suggests heavy contention in the memory allocation subsystem 4. The issue only manifests on Cygwin with bwa; the same code performs normally on native Linux and MacOS Are you saying there is non-bwa code that runs on Cygwin comparably to Linux and Mac? 5. The issue manifests with recent versions of Cygwin but does work with older versions Again, it would really help if you could give Cygwin versions or at least dates here... The issue becomes more pronounced with higher thread counts That I believe; dlmalloc as it is currently set up for Cygwin is not the greatest performer for heavy thread usage. The patched code is located here in branch Cygwin: https://github.com/WGSExtract/bwa.git Simple testsuite. Run bash testsuite.sh. The testsuite includes a version compiled with an older version of Cygwin called bwa_working.exe https://drive.google.com/file/d/1jtbQVUAcCmpJM-8Exi0C6pzDXcEo4cV6/view?usp=drive_link I'll glance at this stuff when I can but I hope to have some answers to my questions above from you to save me some time. ..mark -- 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: Possible issue with check_dir_not_empty
Hello Corinna,
Am 18.11.24 um 17:52 schrieb Corinna Vinschen:
Hi Bernhard,
On Nov 16 23:36, Bernhard Übelacker via Cygwin wrote:
Hello everyone,
Is is about the buffer allocated in check_dir_not_empty.
The pointer pfni gets allocated the buffer at the begin,
and is used in the NtQueryDirectoryFile call before the loops.
In the loop the pointer pfni is also used as iterator.
Therefore it holds no longer the initial buffer at the call
to NtQueryDirectoryFile in the while conditition at the bottom.
Good catch, thank you!
Forgot to mention the background. I actually hit this issue with running
Cygwin's git.exe below a modified Wine checking out the tag 3.5.3 of
newlib-cygwin. Unfortunately reproducing this issue still needs a few
additional Wine patches to finish Cygwin installation.
Attached is a possible modification to always use the allocated buffer.
Kind regards,
Bernhard
Thanks for the patch.
Would you be ok if I apply a simplified version under your authorship?
Rather than add a pfni_it(erator), use pfni as iterator and add a
pfni_buf variable. This is a much smaller patch, and is more in line
with the usual variable naming in Cygwin.
I also added a release message text and a Fixes: line to the commit
message.
Below is the tweaked patch. If you're ok with this version, I'll push
it.
That would be great. Thanks for maintaining Cygwin.
Kind regards,
Bernhard
Thanks,
Corinna
From fbd8b9d769135d6410b423eb9d82b49be52523bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Sat, 16 Nov 2024 18:09:50 +0100
Subject: [PATCH] Cygwin: check_dir_not_empty: Avoid leaving the allocated
buffer.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The pointer pfni gets allocated the buffer at the begin,
and is used in the NtQueryDirectoryFile call before the loops.
In the loop the pointer pfni is also used as iterator.
Therefore it holds no longer the initial buffer at the call
to NtQueryDirectoryFile in the while conditition at the bottom.
Fixes: 28fa2a72f8106 ("* syscalls.cc (check_dir_not_empty): Check surplus directory
entries")
Signed-off-by: Bernhard Übelacker
---
winsup/cygwin/release/3.5.5 | 3 +++
winsup/cygwin/syscalls.cc | 10 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/winsup/cygwin/release/3.5.5 b/winsup/cygwin/release/3.5.5
index 2ca4572db7ed..3088f8682b6b 100644
--- a/winsup/cygwin/release/3.5.5
+++ b/winsup/cygwin/release/3.5.5
@@ -33,3 +33,6 @@ Fixes:
- Fix type of pthread_sigqueue() first parameter to match Linux.
Addresses: https://cygwin.com/pipermail/cygwin/2024-September/256439.html
+
+- Fix potential stack corruption in rmdir() in a border case.
+ Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256774.html
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index df7d3a14efd4..433739cda6e0 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -617,9 +617,10 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
IO_STATUS_BLOCK io;
const ULONG bufsiz = 3 * sizeof (FILE_NAMES_INFORMATION)
+ 3 * NAME_MAX * sizeof (WCHAR);
- PFILE_NAMES_INFORMATION pfni = (PFILE_NAMES_INFORMATION)
-alloca (bufsiz);
- NTSTATUS status = NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni,
+ PFILE_NAMES_INFORMATION pfni_buf = (PFILE_NAMES_INFORMATION)
+alloca (bufsiz);
+ PFILE_NAMES_INFORMATION pfni;
+ NTSTATUS status = NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni_buf,
bufsiz, FileNamesInformation,
FALSE, NULL, TRUE);
if (!NT_SUCCESS (status))
@@ -631,6 +632,7 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
int cnt = 1;
do
{
+ pfni = pfni_buf;
while (pfni->NextEntryOffset)
{
if (++cnt > 2)
@@ -677,7 +679,7 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
pfni = (PFILE_NAMES_INFORMATION) ((caddr_t) pfni +
pfni->NextEntryOffset);
}
}
- while (NT_SUCCESS (NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni,
+ while (NT_SUCCESS (NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni_buf,
bufsiz, FileNamesInformation,
FALSE, NULL, FALSE)));
return STATUS_SUCCESS;
--
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: Possible issue with check_dir_not_empty
Hi Bernhard,
On Nov 16 23:36, Bernhard Übelacker via Cygwin wrote:
> Hello everyone,
>
> Is is about the buffer allocated in check_dir_not_empty.
>
> The pointer pfni gets allocated the buffer at the begin,
> and is used in the NtQueryDirectoryFile call before the loops.
> In the loop the pointer pfni is also used as iterator.
> Therefore it holds no longer the initial buffer at the call
> to NtQueryDirectoryFile in the while conditition at the bottom.
Good catch, thank you!
> Attached is a possible modification to always use the allocated buffer.
>
> Kind regards,
> Bernhard
Thanks for the patch.
Would you be ok if I apply a simplified version under your authorship?
Rather than add a pfni_it(erator), use pfni as iterator and add a
pfni_buf variable. This is a much smaller patch, and is more in line
with the usual variable naming in Cygwin.
I also added a release message text and a Fixes: line to the commit
message.
Below is the tweaked patch. If you're ok with this version, I'll push
it.
Thanks,
Corinna
From fbd8b9d769135d6410b423eb9d82b49be52523bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Sat, 16 Nov 2024 18:09:50 +0100
Subject: [PATCH] Cygwin: check_dir_not_empty: Avoid leaving the allocated
buffer.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The pointer pfni gets allocated the buffer at the begin,
and is used in the NtQueryDirectoryFile call before the loops.
In the loop the pointer pfni is also used as iterator.
Therefore it holds no longer the initial buffer at the call
to NtQueryDirectoryFile in the while conditition at the bottom.
Fixes: 28fa2a72f8106 ("* syscalls.cc (check_dir_not_empty): Check surplus
directory entries")
Signed-off-by: Bernhard Übelacker
---
winsup/cygwin/release/3.5.5 | 3 +++
winsup/cygwin/syscalls.cc | 10 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/winsup/cygwin/release/3.5.5 b/winsup/cygwin/release/3.5.5
index 2ca4572db7ed..3088f8682b6b 100644
--- a/winsup/cygwin/release/3.5.5
+++ b/winsup/cygwin/release/3.5.5
@@ -33,3 +33,6 @@ Fixes:
- Fix type of pthread_sigqueue() first parameter to match Linux.
Addresses: https://cygwin.com/pipermail/cygwin/2024-September/256439.html
+
+- Fix potential stack corruption in rmdir() in a border case.
+ Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256774.html
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index df7d3a14efd4..433739cda6e0 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -617,9 +617,10 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
IO_STATUS_BLOCK io;
const ULONG bufsiz = 3 * sizeof (FILE_NAMES_INFORMATION)
+ 3 * NAME_MAX * sizeof (WCHAR);
- PFILE_NAMES_INFORMATION pfni = (PFILE_NAMES_INFORMATION)
-alloca (bufsiz);
- NTSTATUS status = NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni,
+ PFILE_NAMES_INFORMATION pfni_buf = (PFILE_NAMES_INFORMATION)
+alloca (bufsiz);
+ PFILE_NAMES_INFORMATION pfni;
+ NTSTATUS status = NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni_buf,
bufsiz, FileNamesInformation,
FALSE, NULL, TRUE);
if (!NT_SUCCESS (status))
@@ -631,6 +632,7 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
int cnt = 1;
do
{
+ pfni = pfni_buf;
while (pfni->NextEntryOffset)
{
if (++cnt > 2)
@@ -677,7 +679,7 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
pfni = (PFILE_NAMES_INFORMATION) ((caddr_t) pfni +
pfni->NextEntryOffset);
}
}
- while (NT_SUCCESS (NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni,
+ while (NT_SUCCESS (NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni_buf,
bufsiz, FileNamesInformation,
FALSE, NULL, FALSE)));
return STATUS_SUCCESS;
--
2.47.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: SMBFS mount's file cannot be made executable
On Nov 16 00:21, Takashi Yano via Cygwin wrote:
> I built a test program, whose important part is:
>
> AUTHZ_RESOURCE_MANAGER_HANDLE hManager = NULL;
> AUTHZ_CLIENT_CONTEXT_HANDLE hClient = NULL;
> AUTHZ_ACCESS_REQUEST AccessRequest = {0};
> AUTHZ_ACCESS_REPLY AccessReply = {0};
>
> AUTHZ_RPC_INIT_INFO_CLIENT authzRpcInitInfoClient = {0};
>
> WCHAR ObjectUuid[] = L"9a81c2bd-a525-471d-a4ed-49907c0b23da";
> WCHAR ProtSeq[] = L"ncacn_ip_tcp";
> WCHAR NetworkAddr[] = L"localhost";
> WCHAR Endpoint[] = L"135";
>
> authzRpcInitInfoClient.version = AUTHZ_INIT_INFO_VERSION_V1;
> authzRpcInitInfoClient.ObjectUuid = ObjectUuid;
> authzRpcInitInfoClient.ProtSeq = ProtSeq;
> authzRpcInitInfoClient.NetworkAddr = NetworkAddr;
> authzRpcInitInfoClient.Endpoint = Endpoint;
>
> AuthzInitializeRemoteResourceManager (&authzRpcInitInfoClient, &hManager);
>
> char buf[1024];
> PTOKEN_USER pTokenUser = (PTOKEN_USER) buf;
> DWORD len;
>
> GetTokenInformation(hToken, TokenUser, pTokenUser, 1024, &len);
>
> LUID luid = {0,};
> AuthzInitializeContextFromSid(0, pTokenUser->User.Sid, hManager,
> NULL, luid, NULL, &hClient);
>
>
> This test code fails at AuthzInitializeContextFromSid() with
> RPC_S_UNKNOWN_IF. If AuthzInitializeRemoteResourceManager()
> is replaced with AuthzInitializeResourceManager(), the error
> does not occur.
>
> I searched the combination of AuthzInitializeContextFromSid()
> and RPC_S_UNKNOWN_IF, however nothing was found.
RPC_S_UNKNOWN_IF means "unknown interface". I assume this error has
nothing to do with AuthzInitializeContextFromSid(), but with the
AuthzInitializeRemoteResourceManager() call.
What I failed, though, is to find a working example for
AuthzInitializeRemoteResourceManager().
> Any suggestion would be appreciated.
As I said in my previous posting, maybe we don't really need
AuthzInitializeRemoteResourceManager().
We can safely assume that the current user is already authorized on the
SMB server. So... shouldn't AuthzInitializeResourceManager be
sufficient and the code from class authz_ctx already does what we want?
We may just have to use in in place of calling NtCheckAccess(),
maybe with a tweak or two...
Corinna
--
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
ucrt for mingw compiler (suggestion and wish)
Hi all, The (original) mingw compilers essentially come in the flavours mingw64, ucrt64, clang64. The mingw compilers available via cygwin install are the mingw64 ones. This means they are based on the old M$ C runtime msvcrt instead if the new ucrt one. Woild it be possible to offer the ucrt64 ones, either instead of or in addtion to the msvcrt compilers? Thx and best regards Franz -- 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
Thread memory allocation issue
Hello! I raised this issue couple of years ago on cygwin-developer but now when the problem has manifested again with recent versions of Cygwin I decided to post this to general discussion list. Steps to Reproduce 1. Compile BWA normally https://github.com/lh3/bwa/ 2. Compile BWA with rpmalloc and the following patch: // In thread worker function: #ifdef __CYGWIN__ rpmalloc_thread_initialize(); #endif // ... thread work ... #ifdef __CYGWIN__ rpmalloc_thread_finalize(1); #endif 3. Run both versions with the following command: time ./bwa mem -t 11 chr19_KI270866v1_alt.fasta test_1.fastq test_2.fastq > testorigsingle.sam Without Patch (Default malloc): [M::mem_process_seqs] Processed 12 reads in 30.296 CPU sec, 3.743 real sec [main] Real time: 3.883 sec; CPU: 30.436 sec real 0m3.907s user 0m19.186s sys 0m11.265s With Patch (rpmalloc): [M::mem_process_seqs] Processed 12 reads in 7.530 CPU sec, 0.702 real sec [main] Real time: 0.830 sec; CPU: 7.640 sec real 0m0.868s user 0m7.343s sys 0m0.327s Analysis 1. The default malloc implementation shows extremely high system time (11.265s) compared to the rpmalloc version (0.327s) 2. Total real time is about 4.5x slower with default malloc 3. The dramatic difference in system time suggests heavy contention in the memory allocation subsystem 4. The issue only manifests on Cygwin with bwa; the same code performs normally on native Linux and MacOS 5. The issue manifests with recent versions of Cygwin but does work with older versions The issue becomes more pronounced with higher thread counts The patched code is located here in branch Cygwin: https://github.com/WGSExtract/bwa.git Simple testsuite. Run bash testsuite.sh. The testsuite includes a version compiled with an older version of Cygwin called bwa_working.exe https://drive.google.com/file/d/1jtbQVUAcCmpJM-8Exi0C6pzDXcEo4cV6/view?usp=drive_link Regards, Teemu Nätkinniemi -- 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: New installation of Cygwin64: xinit.sh exit code 3
On 15/11/2024 21:53, Kenneth Freidank via Cygwin wrote:
I too, have this issue, but have not resolved it. I
installed "amd-software-adrenalin-edition-24.10.1-minimalsetup-241031_web.exe".
It seems to be a permissions problem. I am the only user and the only
Yeah, this does indeed seem to be permissions problem, but it only shows
up for (some?) users of Windows 11.
administrator. OS is Win11 Pro, version 10.0.22631 Build 22631. The
permissions seem to be scrambled in the script. I have run the
The /etc/postinstall/xinit.sh{,.done} doesn't script doesn't explicitly
do anything with permissions, it just relies on Cygwin's normal handling
of them (under the default bash umask).
troubleshooting script and attached the output. Can anyone help.
$ for p in "`cygpath -A -P -U`"{,/Cygwin-X}; do for c in 'lsattr -d' 'ls
-dl' getfacl; do $c "$p"; echo; done; icacls "`cygpath -m "$p"`"; done
rn-- /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs
drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Nov 12 21:36
'/proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs'
[...]
This looks normal
d---rwxr-x+ 1 kfreidank Administrators 0 Nov 12 21:36
'/proc/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X'
[...]
This looks odd.
We have no permissions for a directory which we just created and we own.
Even then, we should have permission to create the shortcut there, via
our 'Administrators' group membership, but it's seems we don't.
Puzzling.
--
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
Possible issue with check_dir_not_empty
Hello everyone,
Is is about the buffer allocated in check_dir_not_empty.
The pointer pfni gets allocated the buffer at the begin,
and is used in the NtQueryDirectoryFile call before the loops.
In the loop the pointer pfni is also used as iterator.
Therefore it holds no longer the initial buffer at the call
to NtQueryDirectoryFile in the while conditition at the bottom.
Attached is a possible modification to always use the allocated buffer.
Kind regards,
BernhardFrom 667a8d525879ed1d1ae85cfa81ea356638bd4bd4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Sat, 16 Nov 2024 18:09:50 +0100
Subject: Cygwin: check_dir_not_empty: Avoid leaving the allocated buffer.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The pointer pfni gets allocated the buffer at the begin,
and is used in the NtQueryDirectoryFile call before the loops.
In the loop the pointer pfni is also used as iterator.
Therefore it holds no longer the initial buffer at the call
to NtQueryDirectoryFile in the while conditition at the bottom.
Signed-off-by: Bernhard Übelacker
---
winsup/cygwin/syscalls.cc | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index df7d3a14e..a19879ab2 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -619,6 +619,7 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
+ 3 * NAME_MAX * sizeof (WCHAR);
PFILE_NAMES_INFORMATION pfni = (PFILE_NAMES_INFORMATION)
alloca (bufsiz);
+ PFILE_NAMES_INFORMATION pfni_it;
NTSTATUS status = NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni,
bufsiz, FileNamesInformation,
FALSE, NULL, TRUE);
@@ -631,7 +632,8 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
int cnt = 1;
do
{
- while (pfni->NextEntryOffset)
+ pfni_it = pfni;
+ while (pfni_it->NextEntryOffset)
{
if (++cnt > 2)
{
@@ -639,10 +641,10 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
OBJECT_ATTRIBUTES attr;
FILE_BASIC_INFORMATION fbi;
- pfni = (PFILE_NAMES_INFORMATION)
- ((caddr_t) pfni + pfni->NextEntryOffset);
- RtlInitCountedUnicodeString(&fname, pfni->FileName,
- pfni->FileNameLength);
+ pfni_it = (PFILE_NAMES_INFORMATION)
+ ((caddr_t) pfni_it + pfni_it->NextEntryOffset);
+ RtlInitCountedUnicodeString(&fname, pfni_it->FileName,
+ pfni_it->FileNameLength);
InitializeObjectAttributes (&attr, &fname, 0, dir, NULL);
status = NtQueryAttributesFile (&attr, &fbi);
/* Intensive testing shows that sometimes directories, for which
@@ -674,7 +676,7 @@ check_dir_not_empty (HANDLE dir, path_conv &pc)
return STATUS_DIRECTORY_NOT_EMPTY;
}
}
- pfni = (PFILE_NAMES_INFORMATION) ((caddr_t) pfni + pfni->NextEntryOffset);
+ pfni_it = (PFILE_NAMES_INFORMATION) ((caddr_t) pfni_it + pfni_it->NextEntryOffset);
}
}
while (NT_SUCCESS (NtQueryDirectoryFile (dir, NULL, NULL, 0, &io, pfni,
--
2.39.2
--
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
takes several attempts to get ssh prompt?
Hi. I also have 0patch installed. I will leave this installed (for awhile) until they address this issue. Thanks for confirming the problem. Sorry for the bad title. Lester -- 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
0patch
Hi. I also have 0patch installed. I will leave this installed (for awhile) until they address this issue. Thanks for confirming the problem. Lester -- 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: Segfault in pthread_sigqueue() or sigtimewait()
On Thu, 14 Nov 2024 13:55:36 +0100
Christian Franke wrote:
> After enabling the usage of pthread_sigqueue() in stress-ng, 'stress-ng
> --pthread ...' occasionally reports that child processes failed with
> SIGSEGV.
>
> The problem is unrelated to the recent fix of the signature of
> pthread_sigqueue():
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=1e8c92e
>
> It could be reproduced with Cygwin 3.5.4-1 and with current 3.6.0 TEST
> release if the signature is adjusted.
>
> Testcase (attached):
>
> $ gcc -O2 -o sigfault sigfault.c # Add -DBETA if compiling for a TEST
> release
>
> $ strace -o trace.log ./sigfault
> pthread_create({0xa000188d0}, ...)=0
> pthread_sigqueue(0xa000188d0, SIGUSR1, .)
> sigtimedwait(...)=30 (errno=0)
> ...
> sigtimedwait(...)=30 (errno=0)
> pthread_sigqueue(0xa000188d0, SIGUSR1, .)=0
> pthread_join(0xa000188d0, .)=0
> pthread_create({0xa000188d0}, ...)=0
> pthread_sigqueue(0xa000188d0, SIGUSR1, .)
> sigtimedwait(...)=30 (errno=0)
> pthread_sigqueue(0xa000188d0, SIGUSR1, .)=0
> pthread_join(0xa000188d0, .)=0
> pthread_create({0xa000188d0}, ...)=0
> pthread_sigqueue(0xa000188d0, SIGUSR1, .)
> Segmentation fault
>
> $ cat trace.log
> ...
> 78 103937 [main] sigfault 2074 sig_send: Waiting for pack.wakeup 0x21C
> 80 104017 [sig] sigfault 2074 sigpacket::process: signal 30 processing
> 147 104164 [sigfault] sigfault 2074 __set_errno: int
> sigwait_common(const sigset_t*, siginfo_t*, PLARGE_INTEGER):643 setting
> errno 11
> 103 104267 [sig] sigfault 2074 sigpacket::process: signal 30, signal
> handler 0x1
> 84 104351 [sigfault] sigfault 2074 sigwait_common: returning signal -1
> 81 104432 [sig] sigfault 2074 sigpacket::setup_handler: controlled
> interrupt. stackptr 0x7FFDFE220, stack 0x7FFDFE218, stackptr[-1] 0x100401109
> 78 104510 [sig] sigfault 2074 proc_subproc: args: 4, 1
> 74 104584 [sig] sigfault 2074 proc_subproc: clear waiting threads
> 71 104655 [sig] sigfault 2074 proc_subproc: finished clearing
> 70 104725 [sig] sigfault 2074 proc_subproc: returning 1
> 125 104850 [sig] sigfault 2074 _cygtls::interrupt_setup: armed
> signal_arrived 0x24C, signal 30
> 74 104924 [sig] sigfault 2074 sigpacket::setup_handler: signal 30
> delivered
> 83 105007 [sigfault] sigfault 2074 set_process_mask_delta: oldmask
> 0, newmask 2000, deltamask 2000
> --- Process 9568 (pid: 2074), exception c005 at 0001
> 80 105087 [sig] sigfault 2074 sigpacket::process: returning 1
> --- Process 9568 (pid: 2074) thread 7320 exited with status 0xc005
> --- Process 9568 (pid: 2074) thread 8928 exited with status 0xc005
> --- Process 9568 (pid: 2074) thread 6792 exited with status 0xc005
> --- Process 9568 (pid: 2074) thread 5020 exited with status 0xc005
> --- Process 9568 thread 9020 exited with status 0xc005
> --- Process 9568 exited with status 0xc005
>
> I guess the problem occurs because pthread_sigqueue() is sometimes
> issued after the thread function already returned. The thread pointer
> should be valid until pthread_join() is called. Sorry if I missed something.
Thansk for the report and especially for the test case.
I could reporduce the problem using your test case.
I'll look into this.
--
Takashi Yano
--
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: takes several attempts to get ssh prompt?
On 11/15/2024 7:32 AM, Lester Ingber via Cygwin wrote: Hi. It is taking several attempts to get an ssh prompt, the past few weeks? Has something changed in Cygwin, or is it just my PC? I had a situation a few weeks ago similar to this. ssh and ssh-agent would sometimes just exit without doing anything. For me, it was due to having 0Patch installed. I have not had any issues since I uninstalled 0Patch. -- David Rothenberger daver...@acm.org untold wealth, n.: What you left out on April 15th. -- 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
New installation of Cygwin64: xinit.sh exit code 3
I too, have this issue, but have not resolved it. I
installed "amd-software-adrenalin-edition-24.10.1-minimalsetup-241031_web.exe".
It seems to be a permissions problem. I am the only user and the only
administrator. OS is Win11 Pro, version 10.0.22631 Build 22631. The
permissions seem to be scrambled in the script. I have run the
troubleshooting script and attached the output. Can anyone help.
$ for p in "`cygpath -A -P -U`"{,/Cygwin-X}; do for c in 'lsattr -d' 'ls
-dl' getfacl; do $c "$p"; echo; done; icacls "`cygpath -m "$p"`"; done
rn-- /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs
drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Nov 12 21:36
'/proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs'
# file: /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs
# owner: SYSTEM
# group: SYSTEM
user::rwx
user:kfreidank:r-x
group::r-x
group:Administrators:rwx#effective:r-x
group:Users:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:kfreidank:---
default:group::---
default:group:Administrators:rwx#effective:r-x
default:group:Users:r-x
default:mask::r-x
default:other::r-x
C:/ProgramData/Microsoft/Windows/Start Menu/Programs
S-1-5-21-4172299543-3875418498-3616114757-1000:(I)(OI)(CI)(DE,DC)
S-1-5-21-4172299543-3875418498-3616114757-1001:(I)(OI)(CI)(DE,DC)
S-1-5-21-4172299543-3875418498-3616114757-1002:(I)(OI)(CI)(DE,DC)
GEMWIN\kfreidank:(I)(OI)(CI)(DE,DC)
NT
AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
Everyone:(I)(OI)(CI)(RX)
Successfully processed 1 files; Failed processing 0 files
lsattr: Permission denied while trying to open
/proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin-X
d---rwxr-x+ 1 kfreidank Administrators 0 Nov 12 21:36
'/proc/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X'
# file: /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X
# owner: kfreidank
# group: Administrators
user::---
group::rwx
group:SYSTEM:rwx
group:Users:r-x
mask::rwx
other::r-x
default:user::---
default:group::rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask::rwx
default:other::r-x
C:/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin-X NULL
SID:(DENY)(Rc,REA,WEA,X,DC)
GEMWIN\kfreidank:(DENY)(RD,WD,AD,REA,WEA,X,DC)
GEMWIN\kfreidank:(D,Rc,WDAC,WO,RA,WA)
BUILTIN\Administrators:(RX,W,DC)
NT
AUTHORITY\SYSTEM:(RX,W,DC)
BUILTIN\Users:(RX)
Everyone:(RX)
NULL
SID:(OI)(CI)(IO)(DENY)(Rc,REA,WEA,X,DC)
CREATOR
OWNER:(OI)(CI)(IO)(DENY)(RD,WD,AD,REA,WEA,X,DC)
CREATOR
OWNER:(OI)(CI)(IO)(D,Rc,WDAC,WO,RA,WA)
CREATOR
GROUP:(OI)(CI)(IO)(RX,W,DC)
NT
AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC)
BUILTIN\Users:(OI)(CI)(IO)(RX)
Everyone:(OI)(CI)(IO)(RX)
Successfully processed 1 files; Failed processing 0 files
--
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: takes several attempts to get ssh prompt?
On Friday, November 15, 2024 10:32 AM, Lester Ingber expressed: > > Hi. It is taking several attempts to get an ssh prompt, the past few weeks? > Has something changed in Cygwin, or is it just my PC? > If you are talking about the ssh client, mine works right away. I am totally updated as of yesterday. -- 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
takes several attempts to get ssh prompt?
Hi. It is taking several attempts to get an ssh prompt, the past few weeks? Has something changed in Cygwin, or is it just my PC? Thanks. Lester -- 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: SMBFS mount's file cannot be made executable
On Thu, 14 Nov 2024 01:08:07 +0900
Takashi Yano wrote:
> On Wed, 13 Nov 2024 08:58:21 -0700
> Bill Stewart wrote:
> > On Wed, Nov 13, 2024 at 8:38 AM Takashi Yano via Cygwin wrote:
> >
> > Thanks. However, even after reading the document, I still didn't
> > > understand what strings I should set the members for auth for SMB...
> > >
> > > For example, as for Endpoint, the example for ncacn_np is mentioned,
> > > but not for ncacn_ip_tcp.
> > >
> >
> > Perhaps this might help?
> >
> > https://learn.microsoft.com/en-us/windows/win32/rpc/string-binding
>
> Thanks! I do not read it yet, however, it seems to help much.
I built a test program, whose important part is:
AUTHZ_RESOURCE_MANAGER_HANDLE hManager = NULL;
AUTHZ_CLIENT_CONTEXT_HANDLE hClient = NULL;
AUTHZ_ACCESS_REQUEST AccessRequest = {0};
AUTHZ_ACCESS_REPLY AccessReply = {0};
AUTHZ_RPC_INIT_INFO_CLIENT authzRpcInitInfoClient = {0};
WCHAR ObjectUuid[] = L"9a81c2bd-a525-471d-a4ed-49907c0b23da";
WCHAR ProtSeq[] = L"ncacn_ip_tcp";
WCHAR NetworkAddr[] = L"localhost";
WCHAR Endpoint[] = L"135";
authzRpcInitInfoClient.version = AUTHZ_INIT_INFO_VERSION_V1;
authzRpcInitInfoClient.ObjectUuid = ObjectUuid;
authzRpcInitInfoClient.ProtSeq = ProtSeq;
authzRpcInitInfoClient.NetworkAddr = NetworkAddr;
authzRpcInitInfoClient.Endpoint = Endpoint;
AuthzInitializeRemoteResourceManager (&authzRpcInitInfoClient, &hManager);
char buf[1024];
PTOKEN_USER pTokenUser = (PTOKEN_USER) buf;
DWORD len;
GetTokenInformation(hToken, TokenUser, pTokenUser, 1024, &len);
LUID luid = {0,};
AuthzInitializeContextFromSid(0, pTokenUser->User.Sid, hManager,
NULL, luid, NULL, &hClient);
This test code fails at AuthzInitializeContextFromSid() with
RPC_S_UNKNOWN_IF. If AuthzInitializeRemoteResourceManager()
is replaced with AuthzInitializeResourceManager(), the error
does not occur.
I searched the combination of AuthzInitializeContextFromSid()
and RPC_S_UNKNOWN_IF, however nothing was found.
Any suggestion would be appreciated.
--
Takashi Yano
--
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: cygpath command no longer accepts -s (--short-name) switch
Greetings, Soren! > Hello users. I have a reasonably recently installed Cygwin that I've kept > updated with setup. I am just now seeing that the provided `cygpath` > command no longer works the way it ought to. Could someone(s) confirm or > deny this? And fix it, because it is an important facility. > $ cygpath -ua --short-name '/cygdrive/c/Users/somia/Local Settings' > [dumps you into "help"] > $ cygpath --version > cygpath (cygwin) 3.5.4 > Appreciation in advance for your interest and help. Adding to the previous responses, there could simply be no short name. Check `cmd /C DIR /X`. Or for a more common solution, a batch script like @FOR %%i IN (%*) DO ECHO %%~si will be helpful. Pass it a list of names/paths and it will print the short versions of them line by line. -- With best regards, Andrey Repin Friday, November 15, 2024 15:59:39 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: Configute option --without-cross-bootstrap works in opposite
On 10/11/2024 13:16, Ivan Vorontsov via Cygwin wrote:
I tried to build cygwin from sources. As FAQ suggests I used
--without-cross-bootstrap option to configure to build without using
mingw64-x86_64-gcc-g++. It turns out this option works in opposite. I used
--with-cross-bootstrap option and build went successfully. But that's a
bug, I think.
In file winsup/configure.ac snippet below uses inverted logic:
if test "x$with_cross_bootstrap" != "xyes"; then
AC_CHECK_PROGS(MINGW_CXX, ${target_cpu}-w64-mingw32-g++)
test -n "$MINGW_CXX" || AC_MSG_ERROR([no acceptable MinGW g++ found in
\$PATH])
AC_CHECK_PROGS(MINGW_CC, ${target_cpu}-w64-mingw32-gcc)
test -n "$MINGW_CC" || AC_MSG_ERROR([no acceptable MinGW gcc found in
\$PATH])
fi
AM_CONDITIONAL(CROSS_BOOTSTRAP, [test "x$with_cross_bootstrap" != "xyes"])
I think it should be:
if test "x$with_cross_bootstrap" = "xyes"; then
...
AM_CONDITIONAL(CROSS_BOOTSTRAP, [test "x$with_cross_bootstrap" = "xyes"])
And I think help message should be changed as well.
AC_ARG_WITH([cross-bootstrap],[AS_HELP_STRING([--with-cross-bootstrap],[do
not build programs using the MinGW toolchain or check for MinGW libraries
(useful for bootstrapping a cross-compiler)])],[],[with_cross_bootstrap=no])
to:
AC_ARG_WITH([cross-bootstrap],[AS_HELP_STRING([--without-cross-bootstrap],[do
not build programs using the MinGW toolchain or check for MinGW libraries
(useful for bootstrapping a cross-compiler)])],[],[with_cross_bootstrap=no])
Though, I'm not an expert. All this was found through experimentation.
Thanks for reporting this.
So, this actually looks like a mix-up in [1], where we inverted the
meaning of the option, and it's default, but didn't change the help text.
It is confusing, but I think after that commit, the default is
"--without-cross-bootstrap", with the meaning "I am not doing a
bootstrap, so check for and build everything".
So the help text should probably be changed to read "build programs
using the MinGW toolchain or check for MinGW libraries (disable if you
are bootstrapping a Cygwin-targeted cross-compiler, or don't have a
MinGW compiler available)"
(Of course, in the meantime, the use of AC_WINDOWS_{HEADERS,LIBS} has
been removed, so this option now only has the effects that
'--without-mingw-progs' had.)
So, I'm not entirely sure what to do here.
[1]
https://cygwin.com/cgit/newlib-cygwin/commit/?id=e7e6119241d02241c3d114cff037340c12245393
--
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
Segfault in pthread_sigqueue() or sigtimewait()
After enabling the usage of pthread_sigqueue() in stress-ng, 'stress-ng
--pthread ...' occasionally reports that child processes failed with
SIGSEGV.
The problem is unrelated to the recent fix of the signature of
pthread_sigqueue():
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=1e8c92e
It could be reproduced with Cygwin 3.5.4-1 and with current 3.6.0 TEST
release if the signature is adjusted.
Testcase (attached):
$ gcc -O2 -o sigfault sigfault.c # Add -DBETA if compiling for a TEST
release
$ strace -o trace.log ./sigfault
pthread_create({0xa000188d0}, ...)=0
pthread_sigqueue(0xa000188d0, SIGUSR1, .)
sigtimedwait(...)=30 (errno=0)
...
sigtimedwait(...)=30 (errno=0)
pthread_sigqueue(0xa000188d0, SIGUSR1, .)=0
pthread_join(0xa000188d0, .)=0
pthread_create({0xa000188d0}, ...)=0
pthread_sigqueue(0xa000188d0, SIGUSR1, .)
sigtimedwait(...)=30 (errno=0)
pthread_sigqueue(0xa000188d0, SIGUSR1, .)=0
pthread_join(0xa000188d0, .)=0
pthread_create({0xa000188d0}, ...)=0
pthread_sigqueue(0xa000188d0, SIGUSR1, .)
Segmentation fault
$ cat trace.log
...
78 103937 [main] sigfault 2074 sig_send: Waiting for pack.wakeup 0x21C
80 104017 [sig] sigfault 2074 sigpacket::process: signal 30 processing
147 104164 [sigfault] sigfault 2074 __set_errno: int
sigwait_common(const sigset_t*, siginfo_t*, PLARGE_INTEGER):643 setting
errno 11
103 104267 [sig] sigfault 2074 sigpacket::process: signal 30, signal
handler 0x1
84 104351 [sigfault] sigfault 2074 sigwait_common: returning signal -1
81 104432 [sig] sigfault 2074 sigpacket::setup_handler: controlled
interrupt. stackptr 0x7FFDFE220, stack 0x7FFDFE218, stackptr[-1] 0x100401109
78 104510 [sig] sigfault 2074 proc_subproc: args: 4, 1
74 104584 [sig] sigfault 2074 proc_subproc: clear waiting threads
71 104655 [sig] sigfault 2074 proc_subproc: finished clearing
70 104725 [sig] sigfault 2074 proc_subproc: returning 1
125 104850 [sig] sigfault 2074 _cygtls::interrupt_setup: armed
signal_arrived 0x24C, signal 30
74 104924 [sig] sigfault 2074 sigpacket::setup_handler: signal 30
delivered
83 105007 [sigfault] sigfault 2074 set_process_mask_delta: oldmask
0, newmask 2000, deltamask 2000
--- Process 9568 (pid: 2074), exception c005 at 0001
80 105087 [sig] sigfault 2074 sigpacket::process: returning 1
--- Process 9568 (pid: 2074) thread 7320 exited with status 0xc005
--- Process 9568 (pid: 2074) thread 8928 exited with status 0xc005
--- Process 9568 (pid: 2074) thread 6792 exited with status 0xc005
--- Process 9568 (pid: 2074) thread 5020 exited with status 0xc005
--- Process 9568 thread 9020 exited with status 0xc005
--- Process 9568 exited with status 0xc005
I guess the problem occurs because pthread_sigqueue() is sometimes
issued after the thread function already returned. The thread pointer
should be valid until pthread_join() is called. Sorry if I missed something.
--
Regards,
Christian
#define _GNU_SOURCE
#include
#include
#include
static volatile char started, stop;
static void * threadfunc(void *arg)
{
(void)arg;
started = 1;
while (!stop)
sched_yield();
siginfo_t info = {0};
sigset_t mask; sigemptyset(&mask);
sigaddset(&mask, SIGUSR1);
struct timespec timeout;
timeout.tv_sec = 0; timeout.tv_nsec = 1000;
errno = 0;
int ret = sigtimedwait(&mask, &info, &timeout);
printf("sigtimedwait(...)=%d (errno=%d)\n", ret, errno); fflush(stdout);
return NULL;
}
int main()
{
signal(SIGUSR1, SIG_IGN);
for (int i = 0; i < 1000; i++) {
started = stop = 0;
pthread_t t = NULL;
int ret = pthread_create(&t, NULL, threadfunc, NULL);
printf("pthread_create({%p}, ...)=%d\n", t, ret); fflush(stdout);
if (ret)
return 1;
while (!started)
sched_yield();
stop = 1;
union sigval value = {0};
printf("pthread_sigqueue(%p, SIGUSR1, .)\n", t); fflush(stdout);
#ifdef BETA
ret = pthread_sigqueue(t, SIGUSR1, value);
#else
ret = pthread_sigqueue(&t, SIGUSR1, value);
#endif
printf("pthread_sigqueue(%p, SIGUSR1, .)=%d\n", t, ret); fflush(stdout);
if (ret)
return 1;
ret = pthread_join(t, NULL);
printf("pthread_join(%p, .)=%d\n", t, ret); fflush(stdout);
if (ret)
return 1;
}
printf("done\n");
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: SMBFS mount's file cannot be made executable
On Wed, 13 Nov 2024 08:58:21 -0700 Bill Stewart wrote: > On Wed, Nov 13, 2024 at 8:38 AM Takashi Yano via Cygwin wrote: > > Thanks. However, even after reading the document, I still didn't > > understand what strings I should set the members for auth for SMB... > > > > For example, as for Endpoint, the example for ncacn_np is mentioned, > > but not for ncacn_ip_tcp. > > > > Perhaps this might help? > > https://learn.microsoft.com/en-us/windows/win32/rpc/string-binding Thanks! I do not read it yet, however, it seems to help much. -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Wed, Nov 13, 2024 at 8:38 AM Takashi Yano via Cygwin wrote: Thanks. However, even after reading the document, I still didn't > understand what strings I should set the members for auth for SMB... > > For example, as for Endpoint, the example for ncacn_np is mentioned, > but not for ncacn_ip_tcp. > Perhaps this might help? https://learn.microsoft.com/en-us/windows/win32/rpc/string-binding -- 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: stress-ng --lockmix 1 crashes with *** fatal error - NtCreateEvent(lock): 0xC0000035
On Tue, 12 Nov 2024 15:28:41 +0100 Sebastian Feld wrote: > stress-ng --lockmix 1 crashes on CYGWIN_NT-10.0-19045 > 3.6.0-0.229.g87cd4f3fbd06.x86_64 > > $ stress-ng --lockmix 1 > stress-ng: info: [174] defaulting to a 1 day run per stressor > stress-ng: info: [174] dispatching hogs: 1 lockmix > stress-ng: info: [175] lockmix: exercising file lock types: flock locka lockf > 0 [main] stress-ng 175 C:\cygwin64\bin\stress-ng.exe: *** fatal > error - NtCreateEvent(lock): 0xC035 > stress-ng: warn: [174] metrics-check: > all bogo-op counters are zero, data may be incorrect > stress-ng: info: [174] skipped: 0 > stress-ng: info: [174] passed: 1: lockmix (1) > stress-ng: info: [174] failed: 0 > stress-ng: info: [174] metrics untrustworthy: 0 > stress-ng: info: [174] unsuccessful run completed in 1.28 sec > $ stress-ng: fail: [176] lockmix: fcntl F_SETLK failed, errno=14 (Bad > address) Thanks for the report. I could reproduce the problem with head of git repo. I looked into this problem, and might have found the cause. After enough testing, I'll submit a patch for this issue ASAP. -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Wed, 13 Nov 2024 08:10:52 -0700
Bill Stewart wrote:
> On Wed, Nov 13, 2024 at 2:18 AM Takashi Yano via Cygwin wrote:
>
> I'm working on this, however, I stuck on setting the first parameter
> > of AuthzInitializeRemoteResourceManager(). The most members of structure
> > AUTHZ_RPC_INIT_INFO_CLIENT are PWSTR, and I have no idea what kind of
> > string should be set to each member. Especially Endpoint and ServerSpn.
> >
> > typedef struct _AUTHZ_RPC_INIT_INFO_CLIENT {
> > USHORT version;
> > PWSTR ObjectUuid;
> > PWSTR ProtSeq;
> > PWSTR NetworkAddr;
> > PWSTR Endpoint;
> > PWSTR Options;
> > PWSTR ServerSpn;
> > } AUTHZ_RPC_INIT_INFO_CLIENT, *PAUTHZ_RPC_INIT_INFO_CLIENT;
> >
> > Do you have any idea?
> >
>
> Does this help?
>
> https://learn.microsoft.com/en-us/windows/win32/api/authz/ns-authz-authz_rpc_init_info_client
Thanks. However, even after reading the document, I still didn't
understand what strings I should set the members for auth for SMB...
For example, as for Endpoint, the example for ncacn_np is mentioned,
but not for ncacn_ip_tcp.
--
Takashi Yano
--
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: SMBFS mount's file cannot be made executable
On Wed, Nov 13, 2024 at 2:18 AM Takashi Yano via Cygwin wrote:
I'm working on this, however, I stuck on setting the first parameter
> of AuthzInitializeRemoteResourceManager(). The most members of structure
> AUTHZ_RPC_INIT_INFO_CLIENT are PWSTR, and I have no idea what kind of
> string should be set to each member. Especially Endpoint and ServerSpn.
>
> typedef struct _AUTHZ_RPC_INIT_INFO_CLIENT {
> USHORT version;
> PWSTR ObjectUuid;
> PWSTR ProtSeq;
> PWSTR NetworkAddr;
> PWSTR Endpoint;
> PWSTR Options;
> PWSTR ServerSpn;
> } AUTHZ_RPC_INIT_INFO_CLIENT, *PAUTHZ_RPC_INIT_INFO_CLIENT;
>
> Do you have any idea?
>
Does this help?
https://learn.microsoft.com/en-us/windows/win32/api/authz/ns-authz-authz_rpc_init_info_client
--
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: School Districts Contacts 2024
Hi there, We are excited to offer you a comprehensive email list of school districts that includes key contact information such as phone numbers, email addresses, mailing addresses, company revenue, size, and web addresses. Our databases also cover related industries such as: * K-12 schools * Universities * Vocational schools and training programs * Performing arts schools * Fitness centers and gyms * Child care services and providers * Educational publishers and suppliers If you're interested, we would be happy to provide you with relevant counts and a test file based on your specific requirements. Thank you for your time and consideration, and please let us know if you have any questions or concerns. Thanks, Abigail Foster To remove from this mailing reply with the subject line " LEAVE US". -- 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: SMBFS mount's file cannot be made executable
Hi Corinna,
On Tue, 12 Nov 2024 12:56:15 +0100
Corinna Vinschen wrote:
> On Nov 12 17:54, Takashi Yano via Cygwin wrote:
> > I noticed that the probelm is not only in samba share, but
> > also in Windows share.
> >
> > Yesterday, I used shared resource of the root directory.
> > In that case, access right of Authenticated Users was enabled.
> > However, when I tried resource under the user folder, the access
> > right of Authenticated Users is not assigned as follows.
> >
> > $ icacls '\\kappy3\Share\smb_shared_file.txt'
> > \\kappy3\Share\smb_shared_file.txt NULL SID:(DENY)(Rc,S,X,DC)
> >
> > S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO)
> >NT AUTHORITY\SYSTEM:(DENY)(S,X)
> >BUILTIN\Administrators:(DENY)(S,X)
> >
> > S-1-5-21-2089672436-4097686843-2104605006-513:(R)
> >NT AUTHORITY\SYSTEM:(RX,W)
> >BUILTIN\Administrators:(RX,W)
> >Everyone:(R)
> >
> > Successfully processed 1 files; Failed processing 0 files
> >
> > $ ls -l //kappy3/Share/smb_shared_file.txt
> > -rw-r--r--+ 1 Unknown+User Unknown+Group 0 11月 12 15:50
> > //kappy3/Share/smb_shared_file.txt
> >
> > $ /cygdrive/c/Windows/system32/whoami /USER
> >
> > USER INFORMATION
> >
> >
> > User NameSID
> > ==
> > hp-z230\yano S-1-5-21-1515853178-1880514851-1804962447-1001
> >
> >
> > The file server is not in AD and uses offline account in Windows 11
> > (means no Microsoft Account). The client also uses offline account
> > in Windows 10 too.
> > The server and the client use the same user name and password, so
> > authentication is automatically done.
>
> It's not *that* automatic. Your user SIDs are still different on
> all standalone machines, so they are still different accounts, SID-wise.
>
> > In this case, access() of the current cygwin wrongly refers to the
> > permissions for 'others'.
> >
> > I wonder why the NtAccessCheck() can not handle this situation
> > correctly.
>
> I really can't tell you, but there's
> https://learn.microsoft.com/en-us/windows/win32/secauthz/how-dacls-control-access-to-an-object
> So, apparently, NtAccessCheck only checks the DACL against the
> SID list in the user token. In the above case, the ACL does not
> contain your user account, nor one of the groups you're member
> of. So your account's access is the one for the Everyone entry.
>
> > The process token does not have the privilege of the
> > SIDs in the server side even though the authentication has been
> > done by 'net use' command?
>
> This is one of things puzzeling me for a while. As soon as you
> authenticate to some standalone server for SMB, your access token should
> additionally contain the SID of the server account you authenticated as,
> at least for file access. But that's not the case.
>
> I just stumbled over
> https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/access-checks-windows-apis-return-incorrect-results
>
> It seems to suggest to use AuthZ in a certain way to check permissions.
> Maybe we can replace NtAccessCheck with AuthZ? If we're lucky, we might
> even get away with the already existing code in the authz_ctx class
> defined in sec/helper.cc. If not, we may have to add another function
> method calling AuthzInitializeRemoteResourceManager instead of
> AuthzInitializeResourceManager.
>
> Care to hack up a test?
I'm working on this, however, I stuck on setting the first parameter
of AuthzInitializeRemoteResourceManager(). The most members of structure
AUTHZ_RPC_INIT_INFO_CLIENT are PWSTR, and I have no idea what kind of
string should be set to each member. Especially Endpoint and ServerSpn.
typedef struct _AUTHZ_RPC_INIT_INFO_CLIENT {
USHORT version;
PWSTR ObjectUuid;
PWSTR ProtSeq;
PWSTR NetworkAddr;
PWSTR Endpoint;
PWSTR Options;
PWSTR ServerSpn;
} AUTHZ_RPC_INIT_INFO_CLIENT, *PAUTHZ_RPC_INIT_INFO_CLIENT;
Do you have any idea?
--
Takashi Yano
--
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: stress-ng --lockmix 1 crashes with *** fatal error - NtCreateEvent(lock): 0xC0000035
On Tue, 12 Nov 2024 at 15:29, Sebastian Feld via Cygwin wrote: > > stress-ng --lockmix 1 crashes on CYGWIN_NT-10.0-19045 > 3.6.0-0.229.g87cd4f3fbd06.x86_64 > > $ stress-ng --lockmix 1 > stress-ng: info: [174] defaulting to a 1 day run per stressor > stress-ng: info: [174] dispatching hogs: 1 lockmix > stress-ng: info: [175] lockmix: exercising file lock types: flock locka lockf > 0 [main] stress-ng 175 C:\cygwin64\bin\stress-ng.exe: *** fatal > error - NtCreateEvent(lock): 0xC035 > stress-ng: warn: [174] metrics-check: > all bogo-op counters are zero, data may be incorrect > stress-ng: info: [174] skipped: 0 > stress-ng: info: [174] passed: 1: lockmix (1) > stress-ng: info: [174] failed: 0 > stress-ng: info: [174] metrics untrustworthy: 0 > stress-ng: info: [174] unsuccessful run completed in 1.28 sec > $ stress-ng: fail: [176] lockmix: fcntl F_SETLK failed, errno=14 (Bad > address) > > Sebi OUCH I thought this was fixed with https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=ae181b0ff1226cf38be8a7f03ff19bf869c87f54 @Takashi Did you try to run stress-ng --lockmix 1 with your patches applied? Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur -- 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: same problem, reported 5 Nov 2024
Am 12.11.2024 um 18:04 schrieb Brian.Inglis--- via Cygwin: On 2024-11-12 07:46, Lester Ingber wrote: I think this is gobbledegook for "I do not know"! Your subject month was out by 2! By default, position and title are dynamically set, so anything you use to read them are likely to change them! And mintty may also be in Tektronix or ReGIS terminal emulation modes. Mintty provides Sixel and Tektronix graphics but not Regis. You can easily `man mintty` and look in the Wiki https://github.com/mintty/mintty/wiki if you think there are mintty "commands", for example: https://github.com/mintty/mintty/wiki/CtrlSeqs I don't know of any "commands" per se but these. There are: - user defined key settings that can be set in startup config files to report the output of certain mintty functions; - startup options where you can set title, position, geometry; - option `-R modes` to report lots of information; - log options to dump information during operation; - the system menu Copy Title selection to paste the title into the clipboard; - many xterm/vt/console control escape sequences that report terminal emulator information and change settings: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html -- 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: pdfroff generating blank output
On 2024-11-11 13:33, John Ousterhout via Cygwin wrote:
As of this morning the behavior of pdfroff under Cygwin seems to have
changed for me: the PDF output that it produces is (often) blank:
* It seems to have the right number of pages, but all of the pages are blank.
* I tried several different viewers including Adobe Acrobat, the PDF
displayer in Firefox, and the PDF displayer in VSCode; all show the
same blank output.
* Historically pdfroff has worked consistently for me with no
problems. Files that produce blank output today worked fine in the
past (perhaps a few months ago?).
* The behavior is not totally consistent: some files still work while
others don't. After poking around a bit, I was able to find a
single-line change that flips the behavior between working and not
working. I have attached the file (homa.7), which can be compiled with
"pdfroff -man homa.7 > homa.pdf". In its current form, this file
generates blank output for me. But, if I delete line 561 (".IR
max_incoming /(N+1).") then the file generates viewable output.
* In cases where the output is blank, I tried using "groff -T ascii"
instead, and this produces fine output.
I am also attaching output from "cygcheck -s -v -r > cygcheck.out", in
case that sheds some light.
Any help would be much appreciated; is it possible that I am doing
something wrong?
As pdfroff is a shell script, you can run it with `sh -vx /bin/pdfroff ...` to
see what it is doing;
append ` |& tee pdfroff-blank.log` to capture the output, to get help here about
what it is doing;
ask on the groff list gr...@gnu.org, report a bug to gr...@gnu.org based on:
https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS
and
https://git.savannah.gnu.org/cgit/groff.git/tree/BUG-REPORT
or on the bug tracker:
https://savannah.gnu.org/bugs/?group=groff
As this is Windows, sometimes weird stuff happens, so updating Cygwin packages,
and/or reboot, sometimes fix unexpected weirdness.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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: same problem, reported 5 Nov 2024
On 2024-11-12 07:46, Lester Ingber wrote: I think this is gobbledegook for "I do not know"! Your subject month was out by 2! By default, position and title are dynamically set, so anything you use to read them are likely to change them! And mintty may also be in Tektronix or ReGIS terminal emulation modes. You can easily `man mintty` and look in the Wiki https://github.com/mintty/mintty/wiki if you think there are mintty "commands", for example: https://github.com/mintty/mintty/wiki/CtrlSeqs I don't know of any "commands" per se but these. There are: - user defined key settings that can be set in startup config files to report the output of certain mintty functions; - startup options where you can set title, position, geometry; - option `-R modes` to report lots of information; - log options to dump information during operation; - the system menu Copy Title selection to paste the title into the clipboard; - many xterm/vt/console control escape sequences that report terminal emulator information and change settings: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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
stress-ng --lockmix 1 crashes with *** fatal error - NtCreateEvent(lock): 0xC0000035
stress-ng --lockmix 1 crashes on CYGWIN_NT-10.0-19045 3.6.0-0.229.g87cd4f3fbd06.x86_64 $ stress-ng --lockmix 1 stress-ng: info: [174] defaulting to a 1 day run per stressor stress-ng: info: [174] dispatching hogs: 1 lockmix stress-ng: info: [175] lockmix: exercising file lock types: flock locka lockf 0 [main] stress-ng 175 C:\cygwin64\bin\stress-ng.exe: *** fatal error - NtCreateEvent(lock): 0xC035 stress-ng: warn: [174] metrics-check: all bogo-op counters are zero, data may be incorrect stress-ng: info: [174] skipped: 0 stress-ng: info: [174] passed: 1: lockmix (1) stress-ng: info: [174] failed: 0 stress-ng: info: [174] metrics untrustworthy: 0 stress-ng: info: [174] unsuccessful run completed in 1.28 sec $ stress-ng: fail: [176] lockmix: fcntl F_SETLK failed, errno=14 (Bad address) Sebi -- Sebastian Feld - IT security expert -- 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: stress-ng?
On Tue, Nov 12, 2024 at 1:19 PM Sebastian Feld wrote: > > Where can I use stress-ng used to test Cygwin? > Never mind. Just install it via setup.exe. Sorry Sebi -- Sebastian Feld - IT secruity expert -- 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
stress-ng?
Where can I use stress-ng used to test Cygwin? Sebi -- Sebastian Feld - IT secruity expert -- 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: SMBFS mount's file cannot be made executable
On Nov 12 04:29, Takashi Yano via Cygwin wrote: > On Mon, 11 Nov 2024 14:35:55 +0100 > Corinna Vinschen wrote: > > On Nov 11 21:19, Takashi Yano via Cygwin wrote: > > > On Mon, 11 Nov 2024 13:03:18 +0100 > > > Corinna Vinschen wrote: > > > > On Nov 11 20:40, Takashi Yano via Cygwin wrote: > > > > > On Mon, 11 Nov 2024 20:32:02 +0900 > > > > > Takashi Yano via Cygwin wrote: > > > > > > Even with this patch, the file: > > > > > > > > > > > > yano $ touch samba_test_file.txt > > > > > > yano $ ls -l samba_test_files.txt > > > > > > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt > > > > > > > > > > Oops! This was wrong. > > > > > -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 > > > > > samba_test_file.txt > > > > > > > > That's Samba for you. I applied your patch and created a file > > > > on my share, and the Authenticated Users group was not in the > > > > resulting ACL. Only user, group, and Everyone. > > > > > > > > Either way, I don't think this is the right thing to do. Even if > > > > the group isn't added to the ACL on my machine, it still loks like > > > > a security problem in waiting. > > > > > > Isn't this DACL here used only for access_check() (NtAccessCheck())? > > > In my environment, the Authenticated Users does not appear in the ACL > > > too. > > > > Oh, yeah, right, *blush*. > > > > But it's still not the right thing to do. You convert the Samba ACL > > to a Windows ACL which gives Authenticated Users full permissions. > > So the check_access() function will return false positives, because > > every authenticated user is in the Authenticated Users group and has > > supposedly FILE_ALL_ACCESS. Even if the actual function (read, write, > > execute) will fail, the access() function will claim that every > > authenticated user has RWX perms. > > Ah, right. I have just confirmed that behaviour... > > > AFAICS, the underlying problem is somehow the user mapping. Did you > > try with username map = /foo/bar? > > Yes. However, my user name is 'yano' both in server (Linux) and > client (Windows 10) side. So, I think there is no effect of > 'username map'. I have something like corinna = MY_DOMAIN\corinna in there. Corinna -- 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: SMBFS mount's file cannot be made executable
On Nov 12 17:54, Takashi Yano via Cygwin wrote: > I noticed that the probelm is not only in samba share, but > also in Windows share. > > Yesterday, I used shared resource of the root directory. > In that case, access right of Authenticated Users was enabled. > However, when I tried resource under the user folder, the access > right of Authenticated Users is not assigned as follows. > > $ icacls '\\kappy3\Share\smb_shared_file.txt' > \\kappy3\Share\smb_shared_file.txt NULL SID:(DENY)(Rc,S,X,DC) > > S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) >NT AUTHORITY\SYSTEM:(DENY)(S,X) >BUILTIN\Administrators:(DENY)(S,X) > > S-1-5-21-2089672436-4097686843-2104605006-513:(R) >NT AUTHORITY\SYSTEM:(RX,W) >BUILTIN\Administrators:(RX,W) >Everyone:(R) > > Successfully processed 1 files; Failed processing 0 files > > $ ls -l //kappy3/Share/smb_shared_file.txt > -rw-r--r--+ 1 Unknown+User Unknown+Group 0 11月 12 15:50 > //kappy3/Share/smb_shared_file.txt > > $ /cygdrive/c/Windows/system32/whoami /USER > > USER INFORMATION > > > User NameSID > == > hp-z230\yano S-1-5-21-1515853178-1880514851-1804962447-1001 > > > The file server is not in AD and uses offline account in Windows 11 > (means no Microsoft Account). The client also uses offline account > in Windows 10 too. > The server and the client use the same user name and password, so > authentication is automatically done. It's not *that* automatic. Your user SIDs are still different on all standalone machines, so they are still different accounts, SID-wise. > In this case, access() of the current cygwin wrongly refers to the > permissions for 'others'. > > I wonder why the NtAccessCheck() can not handle this situation > correctly. I really can't tell you, but there's https://learn.microsoft.com/en-us/windows/win32/secauthz/how-dacls-control-access-to-an-object So, apparently, NtAccessCheck only checks the DACL against the SID list in the user token. In the above case, the ACL does not contain your user account, nor one of the groups you're member of. So your account's access is the one for the Everyone entry. > The process token does not have the privilege of the > SIDs in the server side even though the authentication has been > done by 'net use' command? This is one of things puzzeling me for a while. As soon as you authenticate to some standalone server for SMB, your access token should additionally contain the SID of the server account you authenticated as, at least for file access. But that's not the case. I just stumbled over https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/access-checks-windows-apis-return-incorrect-results It seems to suggest to use AuthZ in a certain way to check permissions. Maybe we can replace NtAccessCheck with AuthZ? If we're lucky, we might even get away with the already existing code in the authz_ctx class defined in sec/helper.cc. If not, we may have to add another function method calling AuthzInitializeRemoteResourceManager instead of AuthzInitializeResourceManager. Care to hack up a test? Corinna -- 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
SIGKILL may no longer work after many SIGCONT/SIGSTOP signals
Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
Testcase (attached):
$ gcc -O2 -o manysignals manysignals.c
$ ./manysignals
fork() = 1833
...
fork() = 1848
...
kill(1833, 17)
...
kill(1848, 17)
kill(1833, 9)
...
kill(1848, 9)
waitpid(1833, ., 0)
Run this in second terminal:
$ watch "ps | sed -n '1p;/manysignals/{/sed/d;p}'"
If 'S' appear in the first column, the child processes likely reached
the final SIGSTOP state. This takes some time. The parent process may
still hang in first waitpid() but should not.
If the parent process is aborted with ^C, child processes may be stopped
or left behind. Occasionally a child process that can not be stopped by
Cygwin (kill -9) is left behind.
Tested with ancient (i7-2600K) and more recent (i7-14700K) CPU :-)
Unrelated to the above, but related to 'stress-ng --cpu-sched' which
uses sched_get/setscheduler():
- sched_getscheduler() always returns SCHED_FIFO. As far as I understand
Linux sched(7), this is a non-preemptive real-time policy. The
preemptive SCHED_RR would possibly a more reasonable value.
Unfortunately SCHED_OTHER cannot be used because it would require to
ignore the priority.
- sched_setscheduler() always fails with ENOSYS. It IMO should allow to
set 'param->sched_priority' if 'policy' is equal to the value returned
by sched_getscheduler().
--
Regards,
Christian
#define _GNU_SOURCE
#include
#include
#include
#include
#include
static void xkill(pid_t pid, int sig)
{
printf("kill(%d, %d)\n", (int)pid, sig);
int ret = kill(pid, sig);
if (ret)
perror("kill");
}
int main()
{
// number of child processes
const int nprocs = 16;
// number of SIGSTOP+SIGCONT, ..., SIGSTOP+SIGCONT, SIGSTOP.
const int nstopcont = 10;
pid_t pids[nprocs];
for (int p = 0; p < nprocs; p++) {
pid_t pid = fork();
if (pid == (pid_t)-1) {
perror("fork"); return 1;
}
if (pid == 0) {
cpu_set_t cpus; CPU_ZERO(&cpus);
CPU_SET(0, &cpus);
if (sched_setaffinity(getpid(), sizeof(cpus), &cpus))
perror("setaffinity");
for (;;)
sched_yield();
}
printf("fork() = %d\n", (int)pid);
pids[p] = pid;
}
sleep(1);
for (int i = 0; ; ) {
for (int p = 0; p < nprocs; p++)
xkill(pids[p], SIGSTOP);
if (++i >= nstopcont)
break;
for (int p = 0; p < nprocs; p++)
xkill(pids[p], SIGCONT);
}
for (int p = 0; p < nprocs; p++)
xkill(pids[p], SIGKILL);
for (int p = 0; p < nprocs; p++) {
pid_t pid = pids[p];
printf("waitpid(%d, ., 0)\n", (int)pid); fflush(stdout);
int status;
pid_t ret = waitpid(pid, &status, 0);
if (ret == (pid_t)-1)
perror("waitpid");
}
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: SMBFS mount's file cannot be made executable
On Tue, 12 Nov 2024 04:29:37 +0900 Takashi Yano wrote: > On Mon, 11 Nov 2024 14:35:55 +0100 > Corinna Vinschen wrote: > > On Nov 11 21:19, Takashi Yano via Cygwin wrote: > > > On Mon, 11 Nov 2024 13:03:18 +0100 > > > Corinna Vinschen wrote: > > > > On Nov 11 20:40, Takashi Yano via Cygwin wrote: > > > > > On Mon, 11 Nov 2024 20:32:02 +0900 > > > > > Takashi Yano via Cygwin wrote: > > > > > > Even with this patch, the file: > > > > > > > > > > > > yano $ touch samba_test_file.txt > > > > > > yano $ ls -l samba_test_files.txt > > > > > > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt > > > > > > > > > > Oops! This was wrong. > > > > > -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 > > > > > samba_test_file.txt > > > > > > > > That's Samba for you. I applied your patch and created a file > > > > on my share, and the Authenticated Users group was not in the > > > > resulting ACL. Only user, group, and Everyone. > > > > > > > > Either way, I don't think this is the right thing to do. Even if > > > > the group isn't added to the ACL on my machine, it still loks like > > > > a security problem in waiting. > > > > > > Isn't this DACL here used only for access_check() (NtAccessCheck())? > > > In my environment, the Authenticated Users does not appear in the ACL > > > too. > > > > Oh, yeah, right, *blush*. > > > > But it's still not the right thing to do. You convert the Samba ACL > > to a Windows ACL which gives Authenticated Users full permissions. > > So the check_access() function will return false positives, because > > every authenticated user is in the Authenticated Users group and has > > supposedly FILE_ALL_ACCESS. Even if the actual function (read, write, > > execute) will fail, the access() function will claim that every > > authenticated user has RWX perms. > > Ah, right. I have just confirmed that behaviour... > > > AFAICS, the underlying problem is somehow the user mapping. Did you > > try with username map = /foo/bar? > > Yes. However, my user name is 'yano' both in server (Linux) and > client (Windows 10) side. So, I think there is no effect of > 'username map'. I noticed that the probelm is not only in samba share, but also in Windows share. Yesterday, I used shared resource of the root directory. In that case, access right of Authenticated Users was enabled. However, when I tried resource under the user folder, the access right of Authenticated Users is not assigned as follows. $ icacls '\\kappy3\Share\smb_shared_file.txt' \\kappy3\Share\smb_shared_file.txt NULL SID:(DENY)(Rc,S,X,DC) S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) NT AUTHORITY\SYSTEM:(DENY)(S,X) BUILTIN\Administrators:(DENY)(S,X) S-1-5-21-2089672436-4097686843-2104605006-513:(R) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) Everyone:(R) Successfully processed 1 files; Failed processing 0 files $ ls -l //kappy3/Share/smb_shared_file.txt -rw-r--r--+ 1 Unknown+User Unknown+Group 0 11月 12 15:50 //kappy3/Share/smb_shared_file.txt $ /cygdrive/c/Windows/system32/whoami /USER USER INFORMATION User NameSID == hp-z230\yano S-1-5-21-1515853178-1880514851-1804962447-1001 The file server is not in AD and uses offline account in Windows 11 (means no Microsoft Account). The client also uses offline account in Windows 10 too. The server and the client use the same user name and password, so authentication is automatically done. In this case, access() of the current cygwin wrongly refers to the permissions for 'others'. I wonder why the NtAccessCheck() can not handle this situation correctly. The process token does not have the privilege of the SIDs in the server side even though the authentication has been done by 'net use' command? -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 14:35:55 +0100 Corinna Vinschen wrote: > On Nov 11 21:19, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 13:03:18 +0100 > > Corinna Vinschen wrote: > > > On Nov 11 20:40, Takashi Yano via Cygwin wrote: > > > > On Mon, 11 Nov 2024 20:32:02 +0900 > > > > Takashi Yano via Cygwin wrote: > > > > > Even with this patch, the file: > > > > > > > > > > yano $ touch samba_test_file.txt > > > > > yano $ ls -l samba_test_files.txt > > > > > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt > > > > > > > > Oops! This was wrong. > > > > -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 > > > > samba_test_file.txt > > > > > > That's Samba for you. I applied your patch and created a file > > > on my share, and the Authenticated Users group was not in the > > > resulting ACL. Only user, group, and Everyone. > > > > > > Either way, I don't think this is the right thing to do. Even if > > > the group isn't added to the ACL on my machine, it still loks like > > > a security problem in waiting. > > > > Isn't this DACL here used only for access_check() (NtAccessCheck())? > > In my environment, the Authenticated Users does not appear in the ACL > > too. > > Oh, yeah, right, *blush*. > > But it's still not the right thing to do. You convert the Samba ACL > to a Windows ACL which gives Authenticated Users full permissions. > So the check_access() function will return false positives, because > every authenticated user is in the Authenticated Users group and has > supposedly FILE_ALL_ACCESS. Even if the actual function (read, write, > execute) will fail, the access() function will claim that every > authenticated user has RWX perms. Ah, right. I have just confirmed that behaviour... > AFAICS, the underlying problem is somehow the user mapping. Did you > try with username map = /foo/bar? Yes. However, my user name is 'yano' both in server (Linux) and client (Windows 10) side. So, I think there is no effect of 'username map'. -- Takashi Yano -- 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: same problem, reported 5 Sep 2024
On 2024-11-11 09:26, Lester Ingber via Cygwin wrote: Hi. I still would appreciate some help with Mintty. I recall there is a command for getting the info for a Mintty window, e.g., title, coordinates, etc. What is that command? There are many control sequences which may be used, but you have to be aware of the orders of the arguments, the punctuation in the sequences and responses, and the units implied in the responses: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html I have a 250 line shell script which shows the following (sequences and responses [cat -A] are in the 3rd and 4th columns [unwrapped]): $ xterm-info type features VT420wpSeNThcrl ^[[c^[[?64;1;2;4;6;9;11;15;21;22;28;29c$ type versionmintty v3.7.6-0 ^[[>c^[[>77;30706;0c$ window position 3 px 210+120^[[13t ^[[3;210;120t$ window size 4 px 875x881^[[14;2t^[[4;881;875t$ text position 3 px 219+152^[[13;2t^[[3;219;152t$ text size 4 px 840x840^[[14t ^[[4;840;840t$ text chars 8 ch 120x60 ^[[18t ^[[8;60;120t$ char size 6 px 7x14 ^[[16t ^[[6;14;7t$ screen chars9 ch 274x77 ^[[19t ^[[9;77;274t$ screen size 5 px 1920x1080 ^[[15t ^[[5;1080;1920t$ window status 1 open ^[[11t ^[[1t$ -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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
same problem, reported 5 Sep 2024
Hi. I still would appreciate some help with Mintty. I recall there is a command for getting the info for a Mintty window, e.g., title, coordinates, etc. What is that command? Thanks. Lester -- 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: SMBFS mount's file cannot be made executable
On Nov 11 21:19, Takashi Yano via Cygwin wrote: > On Mon, 11 Nov 2024 13:03:18 +0100 > Corinna Vinschen wrote: > > On Nov 11 20:40, Takashi Yano via Cygwin wrote: > > > On Mon, 11 Nov 2024 20:32:02 +0900 > > > Takashi Yano via Cygwin wrote: > > > > Even with this patch, the file: > > > > > > > > yano $ touch samba_test_file.txt > > > > yano $ ls -l samba_test_files.txt > > > > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt > > > > > > Oops! This was wrong. > > > -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 > > > samba_test_file.txt > > > > That's Samba for you. I applied your patch and created a file > > on my share, and the Authenticated Users group was not in the > > resulting ACL. Only user, group, and Everyone. > > > > Either way, I don't think this is the right thing to do. Even if > > the group isn't added to the ACL on my machine, it still loks like > > a security problem in waiting. > > Isn't this DACL here used only for access_check() (NtAccessCheck())? > In my environment, the Authenticated Users does not appear in the ACL > too. Oh, yeah, right, *blush*. But it's still not the right thing to do. You convert the Samba ACL to a Windows ACL which gives Authenticated Users full permissions. So the check_access() function will return false positives, because every authenticated user is in the Authenticated Users group and has supposedly FILE_ALL_ACCESS. Even if the actual function (read, write, execute) will fail, the access() function will claim that every authenticated user has RWX perms. AFAICS, the underlying problem is somehow the user mapping. Did you try with username map = /foo/bar? Corinna -- 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: SMBFS mount's file cannot be made executable
On Nov 11 22:00, Takashi Yano via Cygwin wrote: > On Mon, 11 Nov 2024 12:59:41 +0100 > Corinna Vinschen wrote: > > On Nov 11 20:19, Takashi Yano via Cygwin wrote: > > > On Mon, 11 Nov 2024 11:56:13 +0100 > > > Corinna Vinschen wrote: > > > > > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > > > On Fri, 8 Nov 2024 14:11:40 +0100 > > > > > Corinna Vinschen wrote: > > > > > > If the server is a Samba share, check if `force unknown acl user = > > > > > > yes' > > > > > > and for the share itself, check that > > > > > > > > > > > > read only = No > > > > > > vfs objects = acl_xattr > > > > > ^^^ > > > > > Thanks! This makes things better. > > > > > At least x permissions are set to executable compiled by gcc. > > > > > > > > > > However, something is still wrong in my environment > > > > > Others permission seems to be reffered in some cases. > > > > > > > > I don't understand. Please run icacls for a just created file on your > > > > Samba share (without the below patch) as well as Windows' `whoami /all'. > > > > > > $ touch samba_test_file.txt > > > $ icacls samba_test_file.txt > > > samba_test_file.txt > > > S-1-5-21-479325430-3041864944-504445739-1000:(R,W,D,WDAC,WO) > > > S-1-5-21-479325430-3041864944-504445739-513:(R) > > > Everyone:(R) > > > > > > This seems reasonable to me. > > > > > > For Windows 11 share, the result is > > > samba_test_file.txt NULL SID:(DENY)(Rc,S,WEA,X,DC) > > > > > > S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) > > > > On Samba S-1-5-21-479325430-3041864944-504445739-1000 > > On Windows S-1-5-21-2089672436-4097686843-2104605006-1001 > > > > Isn't the user mapping off? > > > > It's also not clear where your Windows ACL comes from. When I check the > > permissions on typical Windows folders, Authenticated Users doesn't even > > show up. > > On my machine, > > C:\Users\yano>mkdir \test_folder > > C:\Users\yano>icacls \test_folder > \test_folder BUILTIN\Administrators:(I)(OI)(CI)(F) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(RX) > NT AUTHORITY\Authenticated Users:(I)(M) > NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M) Those are inherited from the parent folder, i. e., C:\. $ icacls C:\\ c:\ S-1-15-3-65536-1888954469-739942743-1668119174-2468466756-4239452838-1296943325-355587736-700089176:(S,RD,X,RA) BUILTIN\Administrators:(OI)(CI)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Users:(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M) NT AUTHORITY\Authenticated Users:(AD) Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW) Funny enough, the C:\ default ACL on servers doesn't contain entries for Authenticated Users. The group Users is tasking its place. Corinna -- 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: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 12:59:41 +0100 Corinna Vinschen wrote: > On Nov 11 20:19, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 11:56:13 +0100 > > Corinna Vinschen wrote: > > > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > > On Fri, 8 Nov 2024 14:11:40 +0100 > > > > Corinna Vinschen wrote: > > > > > If the server is a Samba share, check if `force unknown acl user = > > > > > yes' > > > > > and for the share itself, check that > > > > > > > > > > read only = No > > > > > vfs objects = acl_xattr > > > > ^^^ > > > > Thanks! This makes things better. > > > > At least x permissions are set to executable compiled by gcc. > > > > > > > > However, something is still wrong in my environment > > > > Others permission seems to be reffered in some cases. > > > > > > I don't understand. Please run icacls for a just created file on your > > > Samba share (without the below patch) as well as Windows' `whoami /all'. > > > > $ touch samba_test_file.txt > > $ icacls samba_test_file.txt > > samba_test_file.txt > > S-1-5-21-479325430-3041864944-504445739-1000:(R,W,D,WDAC,WO) > > S-1-5-21-479325430-3041864944-504445739-513:(R) > > Everyone:(R) > > > > This seems reasonable to me. > > > > For Windows 11 share, the result is > > samba_test_file.txt NULL SID:(DENY)(Rc,S,WEA,X,DC) > > > > S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) > > On Samba S-1-5-21-479325430-3041864944-504445739-1000 > On Windows S-1-5-21-2089672436-4097686843-2104605006-1001 > > Isn't the user mapping off? > > It's also not clear where your Windows ACL comes from. When I check the > permissions on typical Windows folders, Authenticated Users doesn't even > show up. On my machine, C:\Users\yano>mkdir \test_folder C:\Users\yano>icacls \test_folder \test_folder BUILTIN\Administrators:(I)(OI)(CI)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) BUILTIN\Users:(I)(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(I)(M) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M) C:\Users\yano>mkdir test_folder C:\Users\yano>icacls test_folder test_folder NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) BUILTIN\Administrators:(I)(OI)(CI)(F) HP-Z230\yano:(I)(OI)(CI)(F) HP-Z230\Administrator:(I)(OI)(CI)(F) I have no idea why the \test_folder is different from \Users\yano\test_folder. -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 12:59:41 +0100 Corinna Vinschen wrote: > On Nov 11 20:19, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 11:56:13 +0100 > > Corinna Vinschen wrote: > > > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > > On Fri, 8 Nov 2024 14:11:40 +0100 > > > > Corinna Vinschen wrote: > > > > > If the server is a Samba share, check if `force unknown acl user = > > > > > yes' > > > > > and for the share itself, check that > > > > > > > > > > read only = No > > > > > vfs objects = acl_xattr > > > > ^^^ > > > > Thanks! This makes things better. > > > > At least x permissions are set to executable compiled by gcc. > > > > > > > > However, something is still wrong in my environment > > > > Others permission seems to be reffered in some cases. > > > > > > I don't understand. Please run icacls for a just created file on your > > > Samba share (without the below patch) as well as Windows' `whoami /all'. > > > > $ touch samba_test_file.txt > > $ icacls samba_test_file.txt > > samba_test_file.txt > > S-1-5-21-479325430-3041864944-504445739-1000:(R,W,D,WDAC,WO) > > S-1-5-21-479325430-3041864944-504445739-513:(R) > > Everyone:(R) > > > > This seems reasonable to me. > > > > For Windows 11 share, the result is > > samba_test_file.txt NULL SID:(DENY)(Rc,S,WEA,X,DC) > > > > S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) > > On Samba S-1-5-21-479325430-3041864944-504445739-1000 > On Windows S-1-5-21-2089672436-4097686843-2104605006-1001 > > Isn't the user mapping off? In my samba environment, 'username map' option is not specified. The SID in different machine is not the same, I think, is it? > On Windows S-1-5-21-2089672436-4097686843-2104605006-1001 This is not same with the my SID on file share client machine. S-1-5-21-1515853178-1880514851-1804962447-1001 > On Windows S-1-5-21-2089672436-4097686843-2104605006-1001 This is my SID on file server (Windows 11 machine). -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 13:03:18 +0100 Corinna Vinschen wrote: > On Nov 11 20:40, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 20:32:02 +0900 > > Takashi Yano via Cygwin wrote: > > > Even with this patch, the file: > > > > > > yano $ touch samba_test_file.txt > > > yano $ ls -l samba_test_files.txt > > > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt > > > > Oops! This was wrong. > > -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 samba_test_file.txt > > That's Samba for you. I applied your patch and created a file > on my share, and the Authenticated Users group was not in the > resulting ACL. Only user, group, and Everyone. > > Either way, I don't think this is the right thing to do. Even if > the group isn't added to the ACL on my machine, it still loks like > a security problem in waiting. Isn't this DACL here used only for access_check() (NtAccessCheck())? In my environment, the Authenticated Users does not appear in the ACL too. -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Nov 11 20:40, Takashi Yano via Cygwin wrote: > On Mon, 11 Nov 2024 20:32:02 +0900 > Takashi Yano via Cygwin wrote: > > Even with this patch, the file: > > > > yano $ touch samba_test_file.txt > > yano $ ls -l samba_test_files.txt > > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt > > Oops! This was wrong. > -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 samba_test_file.txt That's Samba for you. I applied your patch and created a file on my share, and the Authenticated Users group was not in the resulting ACL. Only user, group, and Everyone. Either way, I don't think this is the right thing to do. Even if the group isn't added to the ACL on my machine, it still loks like a security problem in waiting. Corinna -- 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: SMBFS mount's file cannot be made executable
On Nov 11 20:19, Takashi Yano via Cygwin wrote: > On Mon, 11 Nov 2024 11:56:13 +0100 > Corinna Vinschen wrote: > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > On Fri, 8 Nov 2024 14:11:40 +0100 > > > Corinna Vinschen wrote: > > > > If the server is a Samba share, check if `force unknown acl user = yes' > > > > and for the share itself, check that > > > > > > > > read only = No > > > > vfs objects = acl_xattr > > > ^^^ > > > Thanks! This makes things better. > > > At least x permissions are set to executable compiled by gcc. > > > > > > However, something is still wrong in my environment > > > Others permission seems to be reffered in some cases. > > > > I don't understand. Please run icacls for a just created file on your > > Samba share (without the below patch) as well as Windows' `whoami /all'. > > $ touch samba_test_file.txt > $ icacls samba_test_file.txt > samba_test_file.txt > S-1-5-21-479325430-3041864944-504445739-1000:(R,W,D,WDAC,WO) > S-1-5-21-479325430-3041864944-504445739-513:(R) > Everyone:(R) > > This seems reasonable to me. > > For Windows 11 share, the result is > samba_test_file.txt NULL SID:(DENY)(Rc,S,WEA,X,DC) > > S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) On Samba S-1-5-21-479325430-3041864944-504445739-1000 On Windows S-1-5-21-2089672436-4097686843-2104605006-1001 Isn't the user mapping off? It's also not clear where your Windows ACL comes from. When I check the permissions on typical Windows folders, Authenticated Users doesn't even show up. > S-1-5-21-2089672436-4097686843-2104605006-513:(DENY)(S,X) > [...] > NT AUTHORITY\Authenticated Users:(RX,W) > [...] > > Giving all authenticated users full permissions to all your files? > > Unconditionally? That sounds like opening a security hole wide open. > > Does this really mean such thing? Windows 11 share reports here, > access mask 0x001201bf for S-1-5-11 is granted. Isn't this simillar? Well, it's just a group. All authenticated users are member of the group. It's in all user tokens and if it allows everything on a file... Corinna -- 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: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 20:19:28 +0900 Takashi Yano wrote: > On Mon, 11 Nov 2024 11:56:13 +0100 > Corinna Vinschen wrote: > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > On Fri, 8 Nov 2024 14:11:40 +0100 > > > Corinna Vinschen wrote: > > > > If the server is a Samba share, check if `force unknown acl user = yes' > > > > and for the share itself, check that > > > > > > > > read only = No > > > > vfs objects = acl_xattr > > > ^^^ > > > Thanks! This makes things better. > > > At least x permissions are set to executable compiled by gcc. > > > > > > However, something is still wrong in my environment > > > Others permission seems to be reffered in some cases. > > > > I don't understand. Please run icacls for a just created file on your > > Samba share (without the below patch) as well as Windows' `whoami /all'. > > $ touch samba_test_file.txt > $ icacls samba_test_file.txt > samba_test_file.txt > S-1-5-21-479325430-3041864944-504445739-1000:(R,W,D,WDAC,WO) > S-1-5-21-479325430-3041864944-504445739-513:(R) > Everyone:(R) > > This seems reasonable to me. > > For Windows 11 share, the result is > samba_test_file.txt NULL SID:(DENY)(Rc,S,WEA,X,DC) > > S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) > S-1-5-21-2089672436-4097686843-2104605006-513:(DENY)(S,X) > NT AUTHORITY\Authenticated Users:(DENY)(S,X) > NT AUTHORITY\SYSTEM:(DENY)(S,X) > BUILTIN\Administrators:(DENY)(S,X) > BUILTIN\Users:(DENY)(S,X) > S-1-5-21-2089672436-4097686843-2104605006-513:(RX) > NT AUTHORITY\Authenticated Users:(RX,W) > NT AUTHORITY\SYSTEM:(RX,W) > BUILTIN\Administrators:(RX,W) > BUILTIN\Users:(RX) > Everyone:(R) Sorry, I forgot to add result of 'whoami /all'. $ /cygdrive/c/windows/system32/whoami /all USER INFORMATION User NameSID == hp-z230\yano S-1-5-21-1515853178-1880514851-1804962447-1001 GROUP INFORMATION - Group Name Type SID Attributes == == == Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group HP-Z230\docker-users Alias S-1-5-21-1515853178-1880514851-1804962447-1073 Mandatory group, Enabled by default, Enabled group BUILTIN\Performance Log Users AliasS-1-5-32-559 Mandatory group, Enabled by default, Enabled group BUILTIN\Remote Desktop Users AliasS-1-5-32-555 Mandatory group, Enabled by default, Enabled group BUILTIN\Users AliasS-1-5-32-545 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\ローカル アカウント Well-known group S-1-5-113 Mandatory group, Enabled by default, Enabled group LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group Mandatory Label\Medium Mandatory Level LabelS-1-16-8192 PRIVILEGES INFORMATION -- Privilege NameDescription State = SeShutdownPrivilege Shut down the system Disabled Se
Re: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 20:32:02 +0900 Takashi Yano via Cygwin wrote: > Even with this patch, the file: > > yano $ touch samba_test_file.txt > yano $ ls -l samba_test_files.txt > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt Oops! This was wrong. -rw-r--r-- 1 Unknown+User Unix_Group+1000 0 Nov 11 20:25 samba_test_file.txt > cannot be written by other users: > > someone $ echo > samba_test_files.txt > samba_test_files.txt: Permission denied. > > -- > Takashi Yano > > -- > 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 -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 20:19:28 +0900 Takashi Yano via Cygwin wrote: > On Mon, 11 Nov 2024 11:56:13 +0100 > Corinna Vinschen wrote: > > > diff --git a/winsup/cygwin/sec/base.cc b/winsup/cygwin/sec/base.cc > > > index d5e39d281..c519af6e0 100644 > > > --- a/winsup/cygwin/sec/base.cc > > > +++ b/winsup/cygwin/sec/base.cc > > > @@ -681,6 +681,9 @@ convert_samba_sd (security_descriptor &sd_ret) > > >ace->Header.AceFlags)) > > > return; > > >} > > > + /* Samba without AD seems to need this. */ > > > + add_access_allowed_ace (acl, FILE_ALL_ACCESS, > > > + well_known_authenticated_users_sid, acl_len, 0); > > >acl->AclSize = acl_len; > > > > > >RtlCreateSecurityDescriptor (&sd, SECURITY_DESCRIPTOR_REVISION); > > > > > > What do you think? > > > > Giving all authenticated users full permissions to all your files? > > Unconditionally? That sounds like opening a security hole wide open. > > Does this really mean such thing? Windows 11 share reports here, > access mask 0x001201bf for S-1-5-11 is granted. Isn't this simillar? Even with this patch, the file: yano $ touch samba_test_file.txt yano $ ls -l samba_test_files.txt -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt cannot be written by other users: someone $ echo > samba_test_files.txt samba_test_files.txt: Permission denied. -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Mon, 11 Nov 2024 11:56:13 +0100 Corinna Vinschen wrote: > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > On Fri, 8 Nov 2024 14:11:40 +0100 > > Corinna Vinschen wrote: > > > If the server is a Samba share, check if `force unknown acl user = yes' > > > and for the share itself, check that > > > > > > read only = No > > > vfs objects = acl_xattr > > ^^^ > > Thanks! This makes things better. > > At least x permissions are set to executable compiled by gcc. > > > > However, something is still wrong in my environment > > Others permission seems to be reffered in some cases. > > I don't understand. Please run icacls for a just created file on your > Samba share (without the below patch) as well as Windows' `whoami /all'. $ touch samba_test_file.txt $ icacls samba_test_file.txt samba_test_file.txt S-1-5-21-479325430-3041864944-504445739-1000:(R,W,D,WDAC,WO) S-1-5-21-479325430-3041864944-504445739-513:(R) Everyone:(R) This seems reasonable to me. For Windows 11 share, the result is samba_test_file.txt NULL SID:(DENY)(Rc,S,WEA,X,DC) S-1-5-21-2089672436-4097686843-2104605006-1001:(R,W,D,WDAC,WO) S-1-5-21-2089672436-4097686843-2104605006-513:(DENY)(S,X) NT AUTHORITY\Authenticated Users:(DENY)(S,X) NT AUTHORITY\SYSTEM:(DENY)(S,X) BUILTIN\Administrators:(DENY)(S,X) BUILTIN\Users:(DENY)(S,X) S-1-5-21-2089672436-4097686843-2104605006-513:(RX) NT AUTHORITY\Authenticated Users:(RX,W) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) BUILTIN\Users:(RX) Everyone:(R) > > > map acl inherit = Yes > > > store dos attributes = Yes > > > > > > Not sure if that helps, but I don't have any other idea. I'm running > > > Samba in an AD environment and "it works for me" :-P > > > > I looked into this probelm and found the NtAccessCheck() fails > > for my samba environment. > > > > It seems that next patch solves this. > > > > diff --git a/winsup/cygwin/sec/base.cc b/winsup/cygwin/sec/base.cc > > index d5e39d281..c519af6e0 100644 > > --- a/winsup/cygwin/sec/base.cc > > +++ b/winsup/cygwin/sec/base.cc > > @@ -681,6 +681,9 @@ convert_samba_sd (security_descriptor &sd_ret) > > ace->Header.AceFlags)) > > return; > >} > > + /* Samba without AD seems to need this. */ > > + add_access_allowed_ace (acl, FILE_ALL_ACCESS, > > + well_known_authenticated_users_sid, acl_len, 0); > >acl->AclSize = acl_len; > > > >RtlCreateSecurityDescriptor (&sd, SECURITY_DESCRIPTOR_REVISION); > > > > What do you think? > > Giving all authenticated users full permissions to all your files? > Unconditionally? That sounds like opening a security hole wide open. Does this really mean such thing? Windows 11 share reports here, access mask 0x001201bf for S-1-5-11 is granted. Isn't this simillar? -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Nov 11 19:31, Takashi Yano via Cygwin wrote: > On Fri, 8 Nov 2024 14:11:40 +0100 > Corinna Vinschen wrote: > > If the server is a Samba share, check if `force unknown acl user = yes' > > and for the share itself, check that > > > > read only = No > > vfs objects = acl_xattr > ^^^ > Thanks! This makes things better. > At least x permissions are set to executable compiled by gcc. > > However, something is still wrong in my environment > Others permission seems to be reffered in some cases. I don't understand. Please run icacls for a just created file on your Samba share (without the below patch) as well as Windows' `whoami /all'. > > map acl inherit = Yes > > store dos attributes = Yes > > > > Not sure if that helps, but I don't have any other idea. I'm running > > Samba in an AD environment and "it works for me" :-P > > I looked into this probelm and found the NtAccessCheck() fails > for my samba environment. > > It seems that next patch solves this. > > diff --git a/winsup/cygwin/sec/base.cc b/winsup/cygwin/sec/base.cc > index d5e39d281..c519af6e0 100644 > --- a/winsup/cygwin/sec/base.cc > +++ b/winsup/cygwin/sec/base.cc > @@ -681,6 +681,9 @@ convert_samba_sd (security_descriptor &sd_ret) >ace->Header.AceFlags)) > return; >} > + /* Samba without AD seems to need this. */ > + add_access_allowed_ace (acl, FILE_ALL_ACCESS, > + well_known_authenticated_users_sid, acl_len, 0); >acl->AclSize = acl_len; > >RtlCreateSecurityDescriptor (&sd, SECURITY_DESCRIPTOR_REVISION); > > What do you think? Giving all authenticated users full permissions to all your files? Unconditionally? That sounds like opening a security hole wide open. Corinna -- 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: SMBFS mount's file cannot be made executable
Hi Corinna, On Fri, 8 Nov 2024 14:11:40 +0100 Corinna Vinschen wrote: > On Nov 8 20:51, Takashi Yano via Cygwin wrote: > > Hi all, > > > > On Thu, 8 Aug 2019 15:41:55 + > > "Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > > > Hi, > > > > > > Here's the situation, I have a netmount "Z:" but I cannot make any files > > > on it executable from Cygwin: > > > > > > $ mount > > > ... > > > Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) > > > [...] > > > $ ls -l a.exe > > > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe > > > [...] > > > $ chmod a+x a.exe > > > [...] > > > $ ls -l a.exe > > > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe > > > [...] > > > Also, any file that I give the "x" permission from outside Cygwin (e.g. > > > from Linux) on the SMBFS drive "Z:", > > > becomes executable: > > > > Does anyone know what was the conclusion of this issue? > > I have encountered the same issue and cannot find the > > solution so far. > > SMB is really complex, and Samba adds to the complexity. > > If the remote drive is a Windows share, check if the server shares the > folder with "Full Control" for everyone. > > If the server is a Samba share, check if `force unknown acl user = yes' > and for the share itself, check that > > read only = No > vfs objects = acl_xattr ^^^ Thanks! This makes things better. At least x permissions are set to executable compiled by gcc. However, something is still wrong in my environment Others permission seems to be reffered in some cases. > map acl inherit = Yes > store dos attributes = Yes > > Not sure if that helps, but I don't have any other idea. I'm running > Samba in an AD environment and "it works for me" :-P I looked into this probelm and found the NtAccessCheck() fails for my samba environment. It seems that next patch solves this. diff --git a/winsup/cygwin/sec/base.cc b/winsup/cygwin/sec/base.cc index d5e39d281..c519af6e0 100644 --- a/winsup/cygwin/sec/base.cc +++ b/winsup/cygwin/sec/base.cc @@ -681,6 +681,9 @@ convert_samba_sd (security_descriptor &sd_ret) ace->Header.AceFlags)) return; } + /* Samba without AD seems to need this. */ + add_access_allowed_ace (acl, FILE_ALL_ACCESS, + well_known_authenticated_users_sid, acl_len, 0); acl->AclSize = acl_len; RtlCreateSecurityDescriptor (&sd, SECURITY_DESCRIPTOR_REVISION); What do you think? -- Takashi Yano -- 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: SMBFS mount's file cannot be made executable
On Fri, 8 Nov 2024 16:07:11 +
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" wrote:
> I had the issue at work and I asked my Systems team to configure the share
> correctly on the Linux side of the things.
>
> Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
>
> The Z: drive is the "default share", and on which the .exe files are not
> executable.
>
> $ pwd
> /cygdrive/z
> $ cat hello.c
> #include
>
> int main()
> {
> printf("Hello world!\n");
> return 0;
> }
> $ gcc -o helloZ hello.c
> $ ./helloZ
> -bash: ./helloZ: Permission denied
>
> The Y: drive is the same directory on Linux, exported a bit differently:
>
> $ cd /cygdrive/y
> $ gcc -o helloY hello.c
> $ ./helloY
> Hello world!
> $ strip hello{Y,Z}
> $ diff hello{Y,Z}
> $
>
> This is how the Y: drive had been exported from Linux (ours it an AD
> environment too, BTW):
>
> $ tail -n 6 /etc/samba/smb.conf
> [lavr]
> path = /export/home/lavr
> comment = Anton's Local Home Directory
> read only = No
> hosts allow = [:snipped:]
> acl allow execute always = True
Thanks for the information. Unfortunately, this did not help
in my environment. Perhaps, for non-AD environment, I guess.
--
Takashi Yano
--
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: Testing for 32bit or 64bit Cygwin in Makefile?
On 2024-11-06 08:30, Dimitry Andric via Cygwin wrote: On 6 Nov 2024, at 16:11, Sebastian Feld via Cygwin wrote: How can I test in a /usr/bin/make Makefile whether I am running on a 32bit or 64bit Cygwin (not Windows kernel)? Usually in a shell you use "uname -m", or with bash specifically, the $HOSTTYPE variable. However in GNU make you should be able to use the internal variable $(MAKE_HOST). On my Cygwin installation, this gives the value "x86_64-pc-cygwin". Since I do not have any 32-bit Cygwin installation, I cannot tell you what the exact value is, but my guess would be "i386-pc-cygwin", or something like that. Cygwin 32 (no longer supported) was i686-pc-cygwin as are Mingw cross-builds: $ ls -1 /usr/bin/i*-gcc-[0-9]* /usr/bin/i686-w64-mingw32-gcc-6.4.0.exe /usr/bin/i686-w64-mingw32-gcc-7.4.0.exe -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Newer Python? (was: Updated: python 3.8/3.9 packages)
> On Saturday, 9 November 2024 at 04:53:37 pm GMT+2, Jon Turney via Cygwin > wrote: > > On 15/09/2024 12:08, Michael Cook via Cygwin wrote: > > On Sat Dec 23 03:54:54 GMT 2023 Marco Atzeri wrote: > >> Python 3.12 will be in the near future introduced and we will skip 3.10 and > > 3.11. > > > > Is there a place where I can find the latest status of this effort? > > And how can I help? > I'm afraid it seems our python maintainer has no spare time to work on > this at the moment, so I don't think any progress has been made on this. > > So, any assistance would be welcome. > > As a first step: > > * Investigating the hang problem(s?) reported with the python3 3.9.18 > package and coming up with a solution would be very helpful. > > * I suspect the same problem also exists in 3.10+. Confirming or denying > that hypothesis would also be useful. I would suggest using MSYS2's Python 3.12 as a starting point for porting and investigating the hanging issue. MSYS2 has had a working Python 3.12 for a while now and as it is a fork of Cygwin I would assume would speed up porting. https://github.com/msys2/MSYS2-packages/tree/master/python -- 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
Configute option --without-cross-bootstrap works in opposite
I tried to build cygwin from sources. As FAQ suggests I used
--without-cross-bootstrap option to configure to build without using
mingw64-x86_64-gcc-g++. It turns out this option works in opposite. I used
--with-cross-bootstrap option and build went successfully. But that's a
bug, I think.
In file winsup/configure.ac snippet below uses inverted logic:
if test "x$with_cross_bootstrap" != "xyes"; then
AC_CHECK_PROGS(MINGW_CXX, ${target_cpu}-w64-mingw32-g++)
test -n "$MINGW_CXX" || AC_MSG_ERROR([no acceptable MinGW g++ found in
\$PATH])
AC_CHECK_PROGS(MINGW_CC, ${target_cpu}-w64-mingw32-gcc)
test -n "$MINGW_CC" || AC_MSG_ERROR([no acceptable MinGW gcc found in
\$PATH])
fi
AM_CONDITIONAL(CROSS_BOOTSTRAP, [test "x$with_cross_bootstrap" != "xyes"])
I think it should be:
if test "x$with_cross_bootstrap" = "xyes"; then
...
AM_CONDITIONAL(CROSS_BOOTSTRAP, [test "x$with_cross_bootstrap" = "xyes"])
And I think help message should be changed as well.
AC_ARG_WITH([cross-bootstrap],[AS_HELP_STRING([--with-cross-bootstrap],[do
not build programs using the MinGW toolchain or check for MinGW libraries
(useful for bootstrapping a cross-compiler)])],[],[with_cross_bootstrap=no])
to:
AC_ARG_WITH([cross-bootstrap],[AS_HELP_STRING([--without-cross-bootstrap],[do
not build programs using the MinGW toolchain or check for MinGW libraries
(useful for bootstrapping a cross-compiler)])],[],[with_cross_bootstrap=no])
Though, I'm not an expert. All this was found through experimentation.
--
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: Stable SIDs for "None"+'"Administrator" ?
On Nov 9 11:59, Brian Inglis via Cygwin wrote: > Attached a list of stable and local passwd and group sids that might be of > use. > > Note the digit groups after -21- and -80- ids are variable. > > No id what some of the numbers are! I recommend taking a look into https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids and https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab?source=recommendations for a comprehensive list of SIDs and their meaning (well, partially) Corinna -- 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: Stable SIDs for "None"+'"Administrator" ?
Attached a list of stable and local passwd and group sids that might be of use.
Note the digit groups after -21- and -80- ids are variable.
No id what some of the numbers are!
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
On 2024-11-09 11:25, Christian Franke via Cygwin wrote:
Roland Mainz via Cygwin wrote:
On Sat, Nov 9, 2024 at 6:00 PM Corinna Vinschen via Cygwin wrote:
On Nov 9 17:31, Roland Mainz via Cygwin wrote:
Does anyone know a list of SIDs which can be used to get the
user+group accounts for passwd entry "Adminstrator" and group entry
"None" ?
Our problem is that the actual account names vary with the system
locale, e.g. group entry "None" is "Kein" in "de_DE", "Aucun" in
fr_FR etc. ...
... so far we thought we fixed this by doing a lookup via SID, and
then remembering the localised name.
But: The SIDs are apparently not stable between Windows versions.
For example:
snip
# Windows Server 2022/en
$ getent group None
None:S-1-5-21-168624908-967194555-3343779530-513:197121:
# Windows Server 2019
$ getent group None
None:S-1-5-21-3286904461-66123-4220857270-513:197121
snip
They *are* stable in that they are
${Machine-SID}-513
And if there is no such list, would $ mkgroup | egrep
':S-1-5-21-.+-513:' # be a suitable workaround ?
No.
${AD-SID|-513 == "Domain Users"
I have not the faintest idea what the MS guys were thinking at the time,
calling the group "None". This is basically the equivalent of "Domain
Users" for local accounts on machines not being domain controller. A
useful name would have been "Local Users" or "Machine Users", but,
well, it is what it is.
The safe way to check the SID is to fetch the machine SID attach the RID
513, and check for equality.
How can I get the "machine SID", preferably using /usr/bin/getent,
/usr/bin/getconf or /proc ?
If domain info is excluded from mkgroup output, the one and only S-*-513 group
should contain the machine SID:
$ sid=$(mkgroup -l | sed -n 's/[^:]*:\(S-[-0-9]*\)-513:.*$/\1/p')
$ test $(wc -l <<<"$sid") = 1 || echo 'My assumption was wrong :-)'
Passwd Sids
System Independent Passwd Sids
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
System Dependent S-1-5-21-...-500 Passwd Sids
Administrator:*:$GROUPS:$GROUPS:U-$HOSTNAME/Administrator,S-1-5-21----500:/home/Administrator:/bin/bash
DefaultAccount:*:$GROUPS:$GROUPS:U-$HOSTNAME/DefaultAccount,S-1-5-21----503:/home/DefaultAccount:/bin/bash
Guest:*:$GROUPS:$GROUPS:U-$HOSTNAME/Guest,S-1-5-21----501:/home/Guest:/bin/bash
WDAGUtilityAccount:*:$GROUPS:$GROUPS:U-$HOSTNAME/WDAGUtilityAccount,S-1-5-21----504:/home/WDAGUtilityAccount:/bin/bash
Other
NT SERVICE+TrustedInstaller:*:328384:328384:U-NT
SERVICE\TrustedInstaller,S-1-5-80-----2271478464:/:/sbin/nologin
Group Sids
System Independent Group Sids
Authenticated Users:S-1-5-11:11:
RESTRICTED:S-1-5-12:12:
SYSTEM:S-1-5-18:18:
Administrators:S-1-5-32-544:544:
Users:S-1-5-32-545:545:
Guests:S-1-5-32-546:546:
Performance Monitor Users:S-1-5-32-558:558:
Performance Log Users:S-1-5-32-559:559:
Distributed COM Users:S-1-5-32-562:562:
IIS_IUSRS:S-1-5-32-568:568:
Event Log Readers:S-1-5-32-573:573:
Hyper-V Administrators:S-1-5-32-578:578:
Remote Management Users:S-1-5-32-580:580:
System Managed Accounts Group:S-1-5-32-581:581:
Device Owners:S-1-5-32-583:583:
ALL APPLICATION PACKAGES:S-1-15-2-1:69409:
ALL RESTRICTED APP PACKAGES:S-1-15-2-2:69410:
System Dependent S-1-5-21-...-500 Group Sids
None:S-1-5-21----513:$GROUPS:
Other
NT
SERVICE+TrustedInstaller:S-1-5-80-----2271478464:328384:
--
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: Stable SIDs for "None"+'"Administrator" ?
Roland Mainz via Cygwin wrote:
On Sat, Nov 9, 2024 at 6:00 PM Corinna Vinschen via Cygwin
wrote:
On Nov 9 17:31, Roland Mainz via Cygwin wrote:
Does anyone know a list of SIDs which can be used to get the
user+group accounts for passwd entry "Adminstrator" and group entry
"None" ?
Our problem is that the actual account names vary with the system
locale, e.g. group entry "None" is "Kein" in "de_DE", "Aucun" in
fr_FR etc. ...
... so far we thought we fixed this by doing a lookup via SID, and
then remembering the localised name.
But: The SIDs are apparently not stable between Windows versions.
For example:
snip
# Windows Server 2022/en
$ getent group None
None:S-1-5-21-168624908-967194555-3343779530-513:197121:
# Windows Server 2019
$ getent group None
None:S-1-5-21-3286904461-66123-4220857270-513:197121
snip
They *are* stable in that they are
${Machine-SID}-513
And if there is no such list, would $ mkgroup | egrep
':S-1-5-21-.+-513:' # be a suitable workaround ?
No.
${AD-SID|-513 == "Domain Users"
I have not the faintest idea what the MS guys were thinking at the time,
calling the group "None". This is basically the equivalent of "Domain
Users" for local accounts on machines not being domain controller. A
useful name would have been "Local Users" or "Machine Users", but,
well, it is what it is.
The safe way to check the SID is to fetch the machine SID attach the RID
513, and check for equality.
How can I get the "machine SID", preferably using /usr/bin/getent,
/usr/bin/getconf or /proc ?
If domain info is excluded from mkgroup output, the one and only S-*-513
group should contain the machine SID:
$ sid=$(mkgroup -l | sed -n 's/[^:]*:\(S-[-0-9]*\)-513:.*$/\1/p')
$ test $(wc -l <<<"$sid") = 1 || echo 'My assumption was wrong :-)'
--
Regards,
Christian
--
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: Stable SIDs for "None"+'"Administrator" ?
On Sat, Nov 9, 2024 at 6:00 PM Corinna Vinschen via Cygwin
wrote:
> On Nov 9 17:31, Roland Mainz via Cygwin wrote:
> > Does anyone know a list of SIDs which can be used to get the
> > user+group accounts for passwd entry "Adminstrator" and group entry
> > "None" ?
> >
> > Our problem is that the actual account names vary with the system
> > locale, e.g. group entry "None" is "Kein" in "de_DE", "Aucun" in
> > fr_FR etc. ...
> > ... so far we thought we fixed this by doing a lookup via SID, and
> > then remembering the localised name.
> >
> > But: The SIDs are apparently not stable between Windows versions.
> > For example:
> > snip
> > # Windows Server 2022/en
> > $ getent group None
> > None:S-1-5-21-168624908-967194555-3343779530-513:197121:
> > # Windows Server 2019
> > $ getent group None
> > None:S-1-5-21-3286904461-66123-4220857270-513:197121
> > snip
>
> They *are* stable in that they are
>
> ${Machine-SID}-513
>
> > And if there is no such list, would $ mkgroup | egrep
> > ':S-1-5-21-.+-513:' # be a suitable workaround ?
>
> No.
>
> ${AD-SID|-513 == "Domain Users"
>
> I have not the faintest idea what the MS guys were thinking at the time,
> calling the group "None". This is basically the equivalent of "Domain
> Users" for local accounts on machines not being domain controller. A
> useful name would have been "Local Users" or "Machine Users", but,
> well, it is what it is.
>
> The safe way to check the SID is to fetch the machine SID attach the RID
> 513, and check for equality.
How can I get the "machine SID", preferably using /usr/bin/getent,
/usr/bin/getconf or /proc ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
--
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: Stable SIDs for "None"+'"Administrator" ?
On Nov 9 17:31, Roland Mainz via Cygwin wrote:
> Hi!
>
>
>
> Does anyone know a list of SIDs which can be used to get the
> user+group accounts for passwd entry "Adminstrator" and group entry
> "None" ?
>
> Our problem is that the actual account names vary with the system
> locale, e.g. group entry "None" is "Kein" in "de_DE", "Aucun" in
> fr_FR etc. ...
> ... so far we thought we fixed this by doing a lookup via SID, and
> then remembering the localised name.
>
> But: The SIDs are apparently not stable between Windows versions.
> For example:
> snip
> # Windows Server 2022/en
> $ getent group None
> None:S-1-5-21-168624908-967194555-3343779530-513:197121:
> # Windows Server 2019
> $ getent group None
> None:S-1-5-21-3286904461-66123-4220857270-513:197121
> snip
They *are* stable in that they are
${Machine-SID}-513
> And if there is no such list, would $ mkgroup | egrep
> ':S-1-5-21-.+-513:' # be a suitable workaround ?
No.
${AD-SID|-513 == "Domain Users"
I have not the faintest idea what the MS guys were thinking at the time,
calling the group "None". This is basically the equivalent of "Domain
Users" for local accounts on machines not being domain controller. A
useful name would have been "Local Users" or "Machine Users", but,
well, it is what it is.
The safe way to check the SID is to fetch the machine SID attach the RID
513, and check for equality.
Corinna
--
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: Stable SIDs for "None"+'"Administrator" ?
Roland Mainz via Cygwin writes: > But: The SIDs are apparently not stable between Windows versions. All local SID are (necessarily) different for each installation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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
Stable SIDs for "None"+'"Administrator" ?
Hi! Does anyone know a list of SIDs which can be used to get the user+group accounts for passwd entry "Adminstrator" and group entry "None" ? Our problem is that the actual account names vary with the system locale, e.g. group entry "None" is "Kein" in "de_DE", "Aucun" in fr_FR etc. ... ... so far we thought we fixed this by doing a lookup via SID, and then remembering the localised name. But: The SIDs are apparently not stable between Windows versions. For example: snip # Windows Server 2022/en $ getent group None None:S-1-5-21-168624908-967194555-3343779530-513:197121: # Windows Server 2019 $ getent group None None:S-1-5-21-3286904461-66123-4220857270-513:197121 snip And if there is no such list, would $ mkgroup | egrep ':S-1-5-21-.+-513:' # be a suitable workaround ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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: Newer Python? (was: Updated: python 3.8/3.9 packages)
On 15/09/2024 12:08, Michael Cook via Cygwin wrote: On Sat Dec 23 03:54:54 GMT 2023 Marco Atzeri wrote: Python 3.12 will be in the near future introduced and we will skip 3.10 and 3.11. Is there a place where I can find the latest status of this effort? And how can I help? I'm afraid it seems our python maintainer has no spare time to work on this at the moment, so I don't think any progress has been made on this. So, any assistance would be welcome. As a first step: * Investigating the hang problem(s?) reported with the python3 3.9.18 package and coming up with a solution would be very helpful. * I suspect the same problem also exists in 3.10+. Confirming or denying that hypothesis would also be useful. -- 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: Testing for 32bit or 64bit Cygwin in Makefile?
On 9 Nov 2024, at 11:42, Sebastian Feld via Cygwin wrote:
>
> On Wed, Nov 6, 2024 at 4:30 PM Dimitry Andric
> wrote:
>>
>> On 6 Nov 2024, at 16:11, Sebastian Feld via Cygwin wrote:
>>>
>>> How can I test in a /usr/bin/make Makefile whether I am running on a
>>> 32bit or 64bit Cygwin (not Windows kernel)?
>>
>> Usually in a shell you use "uname -m", or with bash specifically, the
>> $HOSTTYPE variable.
>>
>> However in GNU make you should be able to use the internal variable
>> $(MAKE_HOST). On my Cygwin installation, this gives the value
>> "x86_64-pc-cygwin". Since I do not have any 32-bit Cygwin installation, I
>> cannot tell you what the exact value is, but my guess would be
>> "i386-pc-cygwin", or something like that.
>
> I need something which works with bsdmake (/usr/bin/bmake in Cygwin)
> and GNU /usr/bin/make. Moreover, how would a test statement for this
> look like in the Makefile? bmake doesn't have ifeq ()
BSD make has a different style for conditionals, using ".if", ".else", and so
on. These use a more familiar logical operator syntax than GNU make.
It also has a built-in variable MACHINE corresponding to "uname -m" output. So
with bmake you can do:
.if ${MACHINE} == "x86_64"
.info Go here
.else
.info Go there
.endif
However, supporting both GNU make and BSD make in one Makefile is not really
possible unless you use the lowest common denominator syntax, which is just
variable assignments and basic rules.
Otherwise, you would have to write two files, one called GNUmakefile for GNU
make, and one called Makefile for BSD make.
-Dimitry
--
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: Testing for 32bit or 64bit Cygwin in Makefile?
On Wed, Nov 6, 2024 at 4:30 PM Dimitry Andric wrote: > > On 6 Nov 2024, at 16:11, Sebastian Feld via Cygwin wrote: > > > > How can I test in a /usr/bin/make Makefile whether I am running on a > > 32bit or 64bit Cygwin (not Windows kernel)? > > Usually in a shell you use "uname -m", or with bash specifically, the > $HOSTTYPE variable. > > However in GNU make you should be able to use the internal variable > $(MAKE_HOST). On my Cygwin installation, this gives the value > "x86_64-pc-cygwin". Since I do not have any 32-bit Cygwin installation, I > cannot tell you what the exact value is, but my guess would be > "i386-pc-cygwin", or something like that. I need something which works with bsdmake (/usr/bin/bmake in Cygwin) and GNU /usr/bin/make. Moreover, how would a test statement for this look like in the Makefile? bmake doesn't have ifeq () Sebi -- Sebastian Feld - IT secruity expert -- 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: cygpath command no longer accepts -s (--short-name) switch
Thank you, Dimitry, I understand now why it went wrong. I don't know what I
was thinking, trying to combine -u with -s.You example is useful.
Thank you also, Corinna.
--
Soren
On Fri, Nov 8, 2024 at 10:30 AM Dimitry Andric <
dimi...@unified-streaming.com> wrote:
> On 8 Nov 2024, at 16:20, Soren via Cygwin wrote:
> >
> >
> > Hello users. I have a reasonably recently installed Cygwin that I've kept
> > updated with setup. I am just now seeing that the provided `cygpath`
> > command no longer works the way it ought to. Could someone(s) confirm or
> > deny this? And fix it, because it is an important facility.
> >
> > $ cygpath -ua --short-name '/cygdrive/c/Users/somia/Local Settings'
> > [dumps you into "help"]
> > $ cygpath --version
> > cygpath (cygwin) 3.5.4
> >
> > Appreciation in advance for your interest and help.
>
> From the usage message, I think it is intentional:
>
> -s, --short-name print DOS (short) form of NAMEs (with -w, -m only)
>
> So you cannot use -u together with -s/--short-name.
>
> As a workaround, you could try:
>
> cygpath -u $(cygpath -ma --short-name '/cygdrive/c/Users/somia/Local
> Settings')
>
> which would first convert to mixed style ("C:/Users/somia/LOCALS~1"), then
> back to unix style ("/cygdrive/c/Users/somia/LOCALS~1"). I suppose that is
> what you want?
>
> -Dimitry
>
>
--
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: SMBFS mount's file cannot be made executable
I had the issue at work and I asked my Systems team to configure the share
correctly on the Linux side of the things.
Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto)
Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
The Z: drive is the "default share", and on which the .exe files are not
executable.
$ pwd
/cygdrive/z
$ cat hello.c
#include
int main()
{
printf("Hello world!\n");
return 0;
}
$ gcc -o helloZ hello.c
$ ./helloZ
-bash: ./helloZ: Permission denied
The Y: drive is the same directory on Linux, exported a bit differently:
$ cd /cygdrive/y
$ gcc -o helloY hello.c
$ ./helloY
Hello world!
$ strip hello{Y,Z}
$ diff hello{Y,Z}
$
This is how the Y: drive had been exported from Linux (ours it an AD
environment too, BTW):
$ tail -n 6 /etc/samba/smb.conf
[lavr]
path = /export/home/lavr
comment = Anton's Local Home Directory
read only = No
hosts allow = [:snipped:]
acl allow execute always = True
HTH,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> -Original Message-
> From: Takashi Yano
> Sent: Friday, November 08, 2024 6:51 AM
> To: cygwin@cygwin.com
> Cc: Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> Subject: [EXTERNAL] Re: SMBFS mount's file cannot be made executable
>
> Hi all,
>
> On Thu, 8 Aug 2019 15:41:55 +
> "Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > Hi,
> >
> > Here's the situation, I have a netmount "Z:" but I cannot make any files on
> > it executable
> from Cygwin:
> >
> > $ mount
> > ...
> > Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
> >
> > $ cd /cygdrive/z
> >
> > $ pwd
> > /cygdrive/z
> >
> > $ cat a.c
> > #include
> >
> > int main()
> > {
> > printf("Hello world!\n");
> > return 0;
> > }
> >
> > $ gcc -Wall a.c
> >
> > $ echo $?
> > 0
> >
> > $ ./a.exe
> > -bash: ./a.exe: Permission denied
> >
> > $ ls -l a.exe
> > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe
> >
> > $ getfacl.exe a.exe
> > # file: a.exe
> > # owner: lavr
> > # group: cppcore
> > user::rw-
> > user:lavr:rw-
> > group::r--
> > group:cppcore:r--
> > mask::rw-
> > other::r--
> >
> > $ chmod a+x a.exe
> >
> > $ echo $?
> > 0
> >
> > $ ls -l a.exe
> > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe
> >
> > $ getfacl.exe a.exe
> > # file: a.exe
> > # owner: lavr
> > # group: cppcore
> > user::rw-
> > user:lavr:rw-
> > group::r--
> > group:cppcore:r--
> > mask::rw-
> > other::r--
> >
> > $ ./a.exe
> > -bash: ./a.exe: Permission denied
> >
> > What's missing? How to make the file executable, and why chmod() lies
> > about all-good when
> it does nothing?
> > Any ideas please?
> >
> > Thanks!
> >
> > P.S. I have another netmount "drive" (U:) which Cygwin identifies as
> > "netapp", and
> everything works on that drive,
> > regarding the execution permission.
> >
> > U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto)
> >
> > Also, any file that I give the "x" permission from outside Cygwin (e.g.
> > from Linux) on the
> SMBFS drive "Z:",
> > becomes executable:
> >
> > Cygwin> $ gcc -Wall a.c
> >
> > Linux> $ chmod a+x a.exe
> >
> > Cygwin> $ ./a.exe
> > Hello world!
>
> Does anyone know what was the conclusion of this issue?
> I have encountered the same issue and cannot find the
> solution so far.
>
>
> --
> Takashi Yano
> CAUTION: This email originated from outside of the organization. Do not click
> links or open
> attachments unless you recognize the sender and are confident the content is
> safe.
--
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: cygpath command no longer accepts -s (--short-name) switch
On Nov 8 10:20, Soren via Cygwin wrote: > Hello users. I have a reasonably recently installed Cygwin that I've kept > updated with setup. I am just now seeing that the provided `cygpath` > command no longer works the way it ought to. Could someone(s) confirm or > deny this? And fix it, because it is an important facility. > > $ cygpath -ua --short-name '/cygdrive/c/Users/somia/Local Settings' > [dumps you into "help"] > $ cygpath --version > cygpath (cygwin) 3.5.4 > > Appreciation in advance for your interest and help. cygpath -s is not supported with -u. Use -w instead: $ cygpath -wa --short-name /mnt/c/Users/All\ Users/WindowsHolographicDevices/ C:\Users\ALLUSE~1\WINDOW~1 Corinna -- 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: cygpath command no longer accepts -s (--short-name) switch
On 8 Nov 2024, at 16:20, Soren via Cygwin wrote:
>
>
> Hello users. I have a reasonably recently installed Cygwin that I've kept
> updated with setup. I am just now seeing that the provided `cygpath`
> command no longer works the way it ought to. Could someone(s) confirm or
> deny this? And fix it, because it is an important facility.
>
> $ cygpath -ua --short-name '/cygdrive/c/Users/somia/Local Settings'
> [dumps you into "help"]
> $ cygpath --version
> cygpath (cygwin) 3.5.4
>
> Appreciation in advance for your interest and help.
>From the usage message, I think it is intentional:
-s, --short-name print DOS (short) form of NAMEs (with -w, -m only)
So you cannot use -u together with -s/--short-name.
As a workaround, you could try:
cygpath -u $(cygpath -ma --short-name '/cygdrive/c/Users/somia/Local
Settings')
which would first convert to mixed style ("C:/Users/somia/LOCALS~1"), then back
to unix style ("/cygdrive/c/Users/somia/LOCALS~1"). I suppose that is what you
want?
-Dimitry
--
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
cygpath command no longer accepts -s (--short-name) switch
Hello users. I have a reasonably recently installed Cygwin that I've kept updated with setup. I am just now seeing that the provided `cygpath` command no longer works the way it ought to. Could someone(s) confirm or deny this? And fix it, because it is an important facility. $ cygpath -ua --short-name '/cygdrive/c/Users/somia/Local Settings' [dumps you into "help"] $ cygpath --version cygpath (cygwin) 3.5.4 Appreciation in advance for your interest and help. -- 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: SMBFS mount's file cannot be made executable
On Nov 8 20:51, Takashi Yano via Cygwin wrote: > Hi all, > > On Thu, 8 Aug 2019 15:41:55 + > "Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > > Hi, > > > > Here's the situation, I have a netmount "Z:" but I cannot make any files on > > it executable from Cygwin: > > > > $ mount > > ... > > Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) > > [...] > > $ ls -l a.exe > > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe > > [...] > > $ chmod a+x a.exe > > [...] > > $ ls -l a.exe > > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe > > [...] > > Also, any file that I give the "x" permission from outside Cygwin (e.g. > > from Linux) on the SMBFS drive "Z:", > > becomes executable: > > Does anyone know what was the conclusion of this issue? > I have encountered the same issue and cannot find the > solution so far. SMB is really complex, and Samba adds to the complexity. If the remote drive is a Windows share, check if the server shares the folder with "Full Control" for everyone. If the server is a Samba share, check if `force unknown acl user = yes' and for the share itself, check that read only = No vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes Not sure if that helps, but I don't have any other idea. I'm running Samba in an AD environment and "it works for me" :-P Corinna -- 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: SMBFS mount's file cannot be made executable
Hi all,
On Thu, 8 Aug 2019 15:41:55 +
"Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hi,
>
> Here's the situation, I have a netmount "Z:" but I cannot make any files on
> it executable from Cygwin:
>
> $ mount
> ...
> Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
>
> $ cd /cygdrive/z
>
> $ pwd
> /cygdrive/z
>
> $ cat a.c
> #include
>
> int main()
> {
> printf("Hello world!\n");
> return 0;
> }
>
> $ gcc -Wall a.c
>
> $ echo $?
> 0
>
> $ ./a.exe
> -bash: ./a.exe: Permission denied
>
> $ ls -l a.exe
> -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe
>
> $ getfacl.exe a.exe
> # file: a.exe
> # owner: lavr
> # group: cppcore
> user::rw-
> user:lavr:rw-
> group::r--
> group:cppcore:r--
> mask::rw-
> other::r--
>
> $ chmod a+x a.exe
>
> $ echo $?
> 0
>
> $ ls -l a.exe
> -rw-rw-r--+ 1 lavr cppcore 157753 Aug 8 11:29 a.exe
>
> $ getfacl.exe a.exe
> # file: a.exe
> # owner: lavr
> # group: cppcore
> user::rw-
> user:lavr:rw-
> group::r--
> group:cppcore:r--
> mask::rw-
> other::r--
>
> $ ./a.exe
> -bash: ./a.exe: Permission denied
>
> What's missing? How to make the file executable, and why chmod() lies about
> all-good when it does nothing?
> Any ideas please?
>
> Thanks!
>
> P.S. I have another netmount "drive" (U:) which Cygwin identifies as
> "netapp", and everything works on that drive,
> regarding the execution permission.
>
> U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto)
>
> Also, any file that I give the "x" permission from outside Cygwin (e.g. from
> Linux) on the SMBFS drive "Z:",
> becomes executable:
>
> Cygwin> $ gcc -Wall a.c
>
> Linux> $ chmod a+x a.exe
>
> Cygwin> $ ./a.exe
> Hello world!
Does anyone know what was the conclusion of this issue?
I have encountered the same issue and cannot find the
solution so far.
--
Takashi Yano
--
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 seems to ignore SSH_KEY
> >> I haven't used cygport up in a long time - I use git push now, and let > >> scallywag build the packages > > Is this workflow described somewhere? > It sounds interesting. Yes! Git repositories for Cygwin packaging: https://cygwin.com/packaging/repos.html Once you push your .cygport file up to the package's Cygwin git repo, the package build service will try to build it: https://cygwin.com/packaging/build.html -- 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: Test: gcc-14.2.1+20241102-0.1
Am 04.11.2024 um 21:26 schrieb Brian Inglis via Cygwin: On 2024-11-04 12:00, ASSI wrote: The native Gcc compilers have been updated to the latest upstream snapshot version of the gcc-13 branch: gcc-14.2.1+20241102 This build incorporates the experimental v4 patch from T. Yano to use the newlib locale function in libstdc++ so that other locales (aside from "C") become usable. Cygwin does not allow multiple versions of the compilers to be installed concurrently. For this build, the D compiler has been disabled since it does not bootstrap due to the missing Phobos runtime on Cygwin. No testing beyond the compiler testsuite has been done. Libgccjit is now building and part of the release again. I realised there are docs provided only for gcc/g++, objc/objc++, gccint, gfortran, libgccjit, libgomp, libquadmath, but nothing for libstdc++, not even info or man pages. Is there any chance we could possibly get libstdc++.info* or man pages included with the build, or as (a) separate -doc package(s), and possibly other libraries or components where info or man pages are available, and may not currently be built or installed? I struggled to find any Cygwin or online docs mentioning libstdc++, until a poster linked: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html, One upstream refuses to support distros that do not support C++20 compilers! Given that cygwin/-devel is built with the old ABI, is there any point in trying to build libraries/packages that *require* the new ABI features in C++20? I am asking to adopt dependent orphaned packages, just so I *can* rebuild them with the new ABI, so is trying this exercise going to be futile? Mintty fails to build with gcc-14 and gcc-15. There are some peculiar settings of #define WINVER which mintty does for a purpose; however, this was not a problem until gcc-13. 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
tcl v8.6 to v9.x update
Greetings! Are there any plans/interests to update the cygwin distros with tcl v9.0? Right now, cygwin's version is 8.6: $ tclsh % puts $tcl_version 8.6 I am actually in need of it. Thanks. josé -- 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
asa 1.2 - convert ASA Fortran carriage control characters
Hi folks, Would anyone be interested if this POSIX.2(2024) utility was packaged for Cygwin? For more information, see the home page: https://www.ibiblio.org/pub/Linux/devel/lang/fortran/asa-1.1.lsm or the man page: https://man7.org/linux/man-pages/man1/asa.1p.html or if you have man-pages-posix installed, run: $ man [1p] asa License:GPL-2.0-or-later -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Testing for 32bit or 64bit Cygwin in Makefile?
On 6 Nov 2024, at 16:11, Sebastian Feld via Cygwin wrote: > > How can I test in a /usr/bin/make Makefile whether I am running on a > 32bit or 64bit Cygwin (not Windows kernel)? Usually in a shell you use "uname -m", or with bash specifically, the $HOSTTYPE variable. However in GNU make you should be able to use the internal variable $(MAKE_HOST). On my Cygwin installation, this gives the value "x86_64-pc-cygwin". Since I do not have any 32-bit Cygwin installation, I cannot tell you what the exact value is, but my guess would be "i386-pc-cygwin", or something like that. -Dimitry -- 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
Testing for 32bit or 64bit Cygwin in Makefile?
How can I test in a /usr/bin/make Makefile whether I am running on a 32bit or 64bit Cygwin (not Windows kernel)? Sebi -- Sebastian Feld - IT secruity expert -- 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 seems to ignore SSH_KEY
On 05/11/2024 18.29, ASSI via Cygwin wrote: Federico Kircheis via Cygwin writes: I also did a chmod/chown on the file to ensure that the permission where correct. The file with the permission unchanged worked without issues when moved in ~/.ssh. Whatever directory that file resides in must be readable only by the owner or SSH will not use it. Regard, Achim. Mhm, that could be it. I did not try to modify the permission of the directory. -- 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 seems to ignore SSH_KEY
Federico Kircheis via Cygwin writes: > I also did a chmod/chwon on the file to ensure that the permission > where correct. > The file with the permission unchanged worked without issues when > moved in ~/.ssh. Whatever directory that file resides in must be readable only by the owner or SSH will not use it. Regard, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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 seems to ignore SSH_KEY
On 05/11/2024 17.01, Brian Inglis via Cygwin wrote: On 2024-11-05 04:19, Andrew Schulman via Cygwin wrote: On 2024-11-04 12:20, Federico Kircheis via Cygwin wrote: up until recently I've uploaded packages the following way export SSH_KEY=/path/to/id_rsa; cygport /path/to/file.cygport upload but today I got the following error cd: Fatal error: max-retries exceeded I've fixed it by copying my key in the .ssh folder cp $SSH_KEY ~/.ssh/id_rsa cygport /path/to/file.cygport upload So it is not blocking me, but I wanted to know if this was a known bug, or if I am the only one experiencing it. See https://cygwin.github.io/cygport/cygport_conf.html#SSH_KEY or /usr/share/doc/cygport/html/manual/cygport_conf.html#SSH_KEY SSH_KEY DESCRIPTION Path to the SSH private key corresponding to the public key registered for uploading on sourceware. You'll need to set this if your private key isn't already loaded into a running ssh-agent(1), and it doesn't have one of the expected file names such as ~/.ssh/id_rsa. Also, setting this allows cygport to determine if a passphrase is needed to decrypt the key, and only prompt you for a passphrase if it's needed. Otherwise, you'll be prompted for a passphrase every time you upload. Instead of `ssh-agent` and `ssh-add`, you can use `keychain` in your login profile, which allows cross-session sharing, across X and terminal sessions, and logouts, for example: $ eval `/usr/bin/keychain --noask --eval ~/.ssh/id_rsa` then $ keychain ~/.ssh/id_rsa I haven't used cygport up in a long time - I use git push now, and let scallywag build the packages Is this workflow described somewhere? It sounds interesting. - but this does seem like new wrong behavior. Surely he shouldn't have to use keychain to get cygport to work? According to the docs, as you cited, his method should work. Using keychain is just a way of setting up, persisting, and sharing ssh-/gpg-agent sessions, so keys are kept available in long running agent sessions, across login sessions, without requesting passphrase input for some period. Likely the issue could be permissions on his alternate location key file and directory/path, as libraries and clients are getting pickier about security issues and vulnerabilities, and openssh was recently updated, although cygport should diagnose any failures. The message itself appears likely to have come from `lftp` invoked by `cygport ... upload` /usr/share/cygport/lib/pkg_upload.cygpart failing to authenticate a connection, for some reason? Yes, the error message comes from lftp, because when cd is executed it tries to connect (apparently multiple times instead of erroring out immediately, a the beginning I thought it was simply hanging). So far it seems that it should work, I'll try to gather other information next time. I also did a chmod/chwon on the file to ensure that the permission where correct. The file with the permission unchanged worked without issues when moved in ~/.ssh. -- 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: Python 3.x status?
The latest Python in Cygwin, 3.9, reaches end of life in less than a year, 2025-10, according to [0]. Some packages (numpy) are dropping support for 3.9 [1]. Can we please get an update on the status of a newer Python for Cygwin? Thanks! [0] - https://devguide.python.org/versions/ [1] - https://github.com/numpy/numpy/issues/26247 On 10/3/2024 11:55 AM, Robert Terzi via Cygwin wrote: Any updates on a newer Python 3.x for Cygwin? On Dec 23rd, 2023, Marco Atzeri mentioned in an announcement email[0]: "Python 3.12 will be in the near future introduced and we will skip 3.10 and 3.11." That plan was also mentioned in the Feb 29th 2024 announcement[1] from Marco Atzeri, where the test release of Python 3.9.18 was removed. (The problem with 3.9.18 might have been related to "pip install occasionally hangs" [2]. It looks like Python 3.9.16-1 is still the most current release. Have I missed something, or can we get a status update? Thanks! 0 - https://cygwin.com/pipermail/cygwin-announce/2023-December/011437.html 1 - https://cygwin.com/pipermail/cygwin-announce/2024-February/011613.html 2 - https://cygwin.com/pipermail/cygwin/2024-February/255430.html -- 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
how to find coordinates?
I forget the mintty command to find "coordinates", e.g., title, position, etc.? -- 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 seems to ignore SSH_KEY
On 2024-11-05 04:19, Andrew Schulman via Cygwin wrote: On 2024-11-04 12:20, Federico Kircheis via Cygwin wrote: up until recently I've uploaded packages the following way export SSH_KEY=/path/to/id_rsa; cygport /path/to/file.cygport upload but today I got the following error cd: Fatal error: max-retries exceeded I've fixed it by copying my key in the .ssh folder cp $SSH_KEY ~/.ssh/id_rsa cygport /path/to/file.cygport upload So it is not blocking me, but I wanted to know if this was a known bug, or if I am the only one experiencing it. See https://cygwin.github.io/cygport/cygport_conf.html#SSH_KEY or /usr/share/doc/cygport/html/manual/cygport_conf.html#SSH_KEY SSH_KEY DESCRIPTION Path to the SSH private key corresponding to the public key registered for uploading on sourceware. You'll need to set this if your private key isn't already loaded into a running ssh-agent(1), and it doesn't have one of the expected file names such as ~/.ssh/id_rsa. Also, setting this allows cygport to determine if a passphrase is needed to decrypt the key, and only prompt you for a passphrase if it's needed. Otherwise, you'll be prompted for a passphrase every time you upload. Instead of `ssh-agent` and `ssh-add`, you can use `keychain` in your login profile, which allows cross-session sharing, across X and terminal sessions, and logouts, for example: $ eval `/usr/bin/keychain --noask --eval ~/.ssh/id_rsa` then $ keychain ~/.ssh/id_rsa I haven't used cygport up in a long time - I use git push now, and let scallywag build the packages - but this does seem like new wrong behavior. Surely he shouldn't have to use keychain to get cygport to work? According to the docs, as you cited, his method should work. Using keychain is just a way of setting up, persisting, and sharing ssh-/gpg-agent sessions, so keys are kept available in long running agent sessions, across login sessions, without requesting passphrase input for some period. Likely the issue could be permissions on his alternate location key file and directory/path, as libraries and clients are getting pickier about security issues and vulnerabilities, and openssh was recently updated, although cygport should diagnose any failures. The message itself appears likely to have come from `lftp` invoked by `cygport ... upload` /usr/share/cygport/lib/pkg_upload.cygpart failing to authenticate a connection, for some reason? [Tried to look on lftp.tech website, but site access tried to force download and install of some huge Windows "Securigard privacy browser" installer to use the site! Killed and exited!] -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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 seems to ignore SSH_KEY
> On 2024-11-04 12:20, Federico Kircheis via Cygwin wrote: > > up until recently I've uploaded packages the following way > > export SSH_KEY=/path/to/id_rsa; > > cygport /path/to/file.cygport upload > > but today I got the following error > > cd: Fatal error: max-retries exceeded > > I've fixed it by copying my key in the .ssh folder > > cp $SSH_KEY ~/.ssh/id_rsa > > cygport /path/to/file.cygport upload > > So it is not blocking me, but I wanted to know if this was a known bug, or > > if I > > am the only one experiencing it. > > See > https://cygwin.github.io/cygport/cygport_conf.html#SSH_KEY > or > /usr/share/doc/cygport/html/manual/cygport_conf.html#SSH_KEY > > SSH_KEY > > DESCRIPTION > > Path to the SSH private key corresponding to the public key registered for > uploading on sourceware. > You'll need to set this if your private key isn't already loaded into a > running > ssh-agent(1), and it doesn't have one of the expected file names such as > ~/.ssh/id_rsa. > Also, setting this allows cygport to determine if a passphrase is needed to > decrypt the key, and only prompt you for a passphrase if it's needed. > Otherwise, you'll be prompted for a passphrase every time you upload. > > Instead of `ssh-agent` and `ssh-add`, you can use `keychain` in your login > profile, which allows cross-session sharing, across X and terminal sessions, > and > logouts, for example: > $ eval `/usr/bin/keychain --noask --eval ~/.ssh/id_rsa` > then > $ keychain ~/.ssh/id_rsa I haven't used cygport up in a long time - I use git push now, and let scallywag build the packages - but this does seem like new wrong behavior. Surely he shouldn't have to use keychain to get cygport to work? According to the docs, as you cited, his method should work. Andrew -- 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: Is this correct behaviour for 'rev'?
On Mon, Nov 4, 2024 at 9:49 AM ASSI via Cygwin wrote: > > Backwoods BC via Cygwin writes: > > cat fileOfFullPathNames | rev | sed -r -e "s/\./$mySep/" | rev | sort > > -t "$mySep" --key=2.1 | tr "$mySep" '.' > > $ '\0' . Thanks, Achim! That's simpler and avoids 'rev' and its quirks. \x00 will be a problem for ASCII in Unicode and need to avoid sorting on directory names, so a slight change: 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 seems to ignore SSH_KEY
On 2024-11-04 12:20, Federico Kircheis via Cygwin wrote: up until recently I've uploaded packages the following way export SSH_KEY=/path/to/id_rsa; cygport /path/to/file.cygport upload but today I got the following error cd: Fatal error: max-retries exceeded I've fixed it by copying my key in the .ssh folder cp $SSH_KEY ~/.ssh/id_rsa cygport /path/to/file.cygport upload So it is not blocking me, but I wanted to know if this was a known bug, or if I am the only one experiencing it. See https://cygwin.github.io/cygport/cygport_conf.html#SSH_KEY or /usr/share/doc/cygport/html/manual/cygport_conf.html#SSH_KEY SSH_KEY DESCRIPTION Path to the SSH private key corresponding to the public key registered for uploading on sourceware. You'll need to set this if your private key isn't already loaded into a running ssh-agent(1), and it doesn't have one of the expected file names such as ~/.ssh/id_rsa. Also, setting this allows cygport to determine if a passphrase is needed to decrypt the key, and only prompt you for a passphrase if it's needed. Otherwise, you'll be prompted for a passphrase every time you upload. Instead of `ssh-agent` and `ssh-add`, you can use `keychain` in your login profile, which allows cross-session sharing, across X and terminal sessions, and logouts, for example: $ eval `/usr/bin/keychain --noask --eval ~/.ssh/id_rsa` then $ keychain ~/.ssh/id_rsa -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: [Ms-nfs41-client-devel] Windows Server NFS, getfact not working on NFS
On Wed, Oct 30, 2024 at 8:46 AM Cedric Blancher via Cygwin wrote: > > On Tue, 29 Oct 2024 at 15:38, Corinna Vinschen via Cygwin > wrote: > > > > On Oct 29 13:56, Martin Wege via Cygwin wrote: > > > On Sun, Oct 6, 2024 at 8:53 AM Cedric Blancher > > > wrote: > > > > Please run winfsinfo on the NFS filesystem: > > > > /bin/winfsinfo getvolumeinfo "$(cygpath -w /cygdrive/n/nfsshare1)" > > > > > > > > Does winfsinfo getvolumeinfo list the FILE_PERSISTENT_ACLS flag in that > > > > output? > > > > > > No, FILE_PERSISTENT_ACLS is not in that output. > > > > > > Reading > > > https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa > > > it means that the Windows NFSv4.1 server does not support ACLs? > > > > https://learn.microsoft.com/en-us/answers/questions/1132611/windows-nfs-server-acls > > > > That link is not correct: The Windows Server 2019/2022 NFSv4.1 server > could support NFSv4 ACLs if it exports NTFS. > Code is even there. Just M$ didn't find a willing&paying customer to enable > it. So, find a Microsoft sales representative and throw millions of $$$ at them? Thanks, Martin -- 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: Test: gcc-14.2.1+20241102-0.1
On 2024-11-04 12:00, ASSI wrote: The native Gcc compilers have been updated to the latest upstream snapshot version of the gcc-13 branch: gcc-14.2.1+20241102 This build incorporates the experimental v4 patch from T. Yano to use the newlib locale function in libstdc++ so that other locales (aside from "C") become usable. Cygwin does not allow multiple versions of the compilers to be installed concurrently. For this build, the D compiler has been disabled since it does not bootstrap due to the missing Phobos runtime on Cygwin. No testing beyond the compiler testsuite has been done. Libgccjit is now building and part of the release again. I realised there are docs provided only for gcc/g++, objc/objc++, gccint, gfortran, libgccjit, libgomp, libquadmath, but nothing for libstdc++, not even info or man pages. Is there any chance we could possibly get libstdc++.info* or man pages included with the build, or as (a) separate -doc package(s), and possibly other libraries or components where info or man pages are available, and may not currently be built or installed? I struggled to find any Cygwin or online docs mentioning libstdc++, until a poster linked: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html, One upstream refuses to support distros that do not support C++20 compilers! Given that cygwin/-devel is built with the old ABI, is there any point in trying to build libraries/packages that *require* the new ABI features in C++20? I am asking to adopt dependent orphaned packages, just so I *can* rebuild them with the new ABI, so is trying this exercise going to be futile? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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 seems to ignore SSH_KEY
Hello, up until recently I've uploaded packages the following way export SSH_KEY=/path/to/id_rsa; cygport /path/to/file.cygport upload but today I got the following error cd: Fatal error: max-retries exceeded I've fixed it by copying my key in the .ssh folder cp $SSH_KEY ~/.ssh/id_rsa cygport /path/to/file.cygport upload So it is not blocking me, but I wanted to know if this was a known bug, or if I am the only one experiencing it. Best Federico -- 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
Fwd: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11+WindowsServer 2019 for testing, 2024-11-04 ...
Good evening!
For your consideration - we need FEEDBACK, please!
New is:
- WSL (Windows Services for Linux) support
- Windows Server (2019) support
- Global mounts visible to all users
- idmapper support for localised account/group names (French!)
- Many WinSG (newgrp-like utility for Windows) fixes
- Fixes for 32bit applications on 64bit Windows
- Better nfs://-URL support
- public NFS/WebNFS support
- NFSv4 referral support
- more precise timestamps on file generation
- better ReactOS compat
Ced
-- Forwarded message -
From: Roland Mainz
Date: Mon, 4 Nov 2024 at 13:13
Subject: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client
Windows driver binaries for Windows 10/11+WindowsServer 2019 for
testing, 2024-11-04 ...
To:
Hi!
We've created a set of test binaries for the NFSv4.1 filesystem client
driver for Windows 10/11+Windows Server 2019, based on
https://github.com/kofemann/ms-nfs41-client (commit id
#ff72667deb07da4636f67352ff8a84ce0bc3c3f4, git bundle in tarball), for
testing and feedback (download URL in "Download" section below).
Please send comments, bugs, test reports, complaints etc. to the
MailMan mailing list at
https://sourceforge.net/projects/ms-nfs41-client/lists/ms-nfs41-client-devel
# 1. What is this ?
NFSv4.1 filesystem driver for Windows 10/11&Windows Server 2019
# 2. Features:
- Full NFSv4.1 protocol support
- idmapper (mapping usernames and uid/gid values between server and
client)
- Support for custom ports (NFSv4 defaults to TCP port 2049, this
client can use different ports per mount)
- Support for nfs://-URLs
* Why ? nfs://-URLs are crossplatform, portable and Character-Encoding
independent descriptions of NFSv4 server resources (exports).
- including custom ports and raw IPv6 addresses
- nfs://-URL conversion utility (/usr/bin/nfsurlconv) to convert
URLs, including non-ASCII/Unicode characters in mount path
- Support ssh forwarding, e.g. mounting NFSv4 filesystems via ssh
tunnel
- Support for long paths (up to 4096 bytes), no Windows MAXPATH limit
- Unicode support
- File names can use any Unicode character supported by
the NFS server's filesystem.
- nfs://-URLs can be used to mount filesystems with non-ASCII
characters in the mount path, independent of current locale.
- UNC paths
- Mounting UNC paths without DOS driver letter
- IPv6 support in UNC paths
- /sbin/nfs_mount prints UNC paths in Win32+Cygwin formats
- Cygwin bash+ksh93 support UNC paths, e.g.
cd //derfwnb4966@2049/nfs4/bigdisk/mysqldb4/
- WSL support
- Mount Windows NFSv4.1 shares via driver letter or UNC path
in WSL via mount -t drvfs
- Supports NFS owner/group to WSL uid/gid mapping
- IPv6 support
- IPv6 address within '[', ']'
(will be converted to *.ipv6-literal.net)
- Windows ACLs <---> NFSv4 ACL translation
- Win32 C:\Windows\system32\icacls.exe
- Cygwin /usr/bin/setfacl+/usr/bin/getfacl
- Windows Explorer ACL dialog
- Support for NFSv4 public mounts (i.e. use the NFSv4 public file handle
lookup protocol via $ nfs_mount -o public ... #)
- Support for NFSv4 referrals
- See Linux export(5) refer= option, nfsref(5) or
https://docs.oracle.com/cd/E86824_01/html/E54764/nfsref-1m.html
- SFU/Cygwin support, including:
- uid/gid
- Cygwin symlinks
- Custom primary group support
- Supports primary group changes in the calling process/thread
(via |SetTokenInformation(..., TokenPrimaryGroup,...)|), e.g.
if the calling process/threads switches the primary group
in its access token then the NFSv4.1 client will use that
group as GID for file creation.
- newgrp(1)/sg(1)-style "winsg" utilty to run cmd.exe with
different primary group, e.g.
$ winsg [-] -g group [-c command | /C command] #
- Software compatibility:
- Any NFSv4.1 server (Linux, Solaris, Illumos, FreeBSD, nfs4j,
...)
- All tools from Cygwin/MinGW
- Visual Studio
- VMware Workstation (can use VMs hosted on NFSv4.1 filesystem)
# 3. Requirements:
- Windows 10 (32bit or 64bit), Windows 11 or Windows Server 2019
- Cygwin:
- Cygwin versions:
- 64bit: >= 3.5.3 (or 3.6.x-devel)
- 32bit: >= 3.3.6
- Packages (required):
cygwin
cygwin-devel
cygrunsrv
cygutils
cygutils-extra
bash
bzip2
coreutils
getent
gdb
grep
hostname
less
libiconv
libiconv2
pax
pbzip2
procps-ng
sed
tar
time
util-linux
wget
- Packages (recommended):
libnfs-utils (for /usr/bin/nfs-ls)
make
bmake
git
gcc-core
gcc-g++
clang
mingw64-i686-clang
mingw64-x86_64-clang
dos2unix
unzip
bison
cygpor
Re: Is this correct behaviour for 'rev'?
Backwoods BC via Cygwin writes: > cat fileOfFullPathNames | rev | sed -r -e "s/\./$mySep/" | rev | sort > -t "$mySep" --key=2.1 | tr "$mySep" '.' $ + Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: Is this correct behaviour for 'rev'?
Am 04.11.2024 um 12:10 schrieb Backwoods BC via Cygwin: On Sun, Nov 3, 2024 at 11:42 PM Thomas Wolff via Cygwin wrote: Am 04.11.2024 um 05:56 schrieb Backwoods BC via Cygwin: On Sun, Nov 3, 2024 at 1:49 AM Mark Geisert via Cygwin wrote: Continuing my monologue, with due consideration of comments posted, ... On 10/23/2024 10:01 PM, Mark Geisert via Cygwin wrote: Replying to myself, I continue... On 10/22/2024 10:33 PM, Mark Geisert via Cygwin wrote: On 10/22/2024 8:00 PM, Backwoods BC via Cygwin wrote: It appears that 'rev' is choking on any character \x80 or higher, but is OK with those \x1f or smaller. It doesn't give an error or ignore it, it just stops. I don't have access to a Linux box so I can't see if this happens there and nothing in the documentation suggests that this is the correct functionality. Test case: printf 'no non-ASCII characters\nhex 01 >\x01< here\nhex 80 >\x80< here\nLine 4\n'|rev|rev This is for "rev from util-linux 2.33.1" I don't have the current version of 'rev' on my system due to not having updated in a while. I accidentally screwed up my installation and have been reluctant to wipe it and start over. So, is this the expected behaviour for the current version of 'rev' under Cygwin and/or Linux? The current Cygwin util-linux 2.39.3-2 rev behaves in the same, broken way. It looks like line-ending char(s) are not being handled correctly. Don't know yet if it's rev itself or fgetws() being used by rev that's busted. I'll investigate further. Thanks for the report! This is a locale issue. In the default Cygwin locale, rev mishandles the \x80 byte and instead of stopping with an error message it enters an infinite loop. I'll probably report this upstream instead of working out a local fix. Upstream util-linux 2.40.2 has an updated 'rev' that stops with an error message when the OP's testcase is tried. I'm testing the full 2.40.2 for Cygwin release before too long. There is a work-around: change to the "C" locale just to run rev. LC_ALL=C rev zzz where zzz is a file containing your four lines. You can also run your original testcase with "rev" replaced by "LC_ALL=C rev" in both places. Implicit in that suggestion is that the OP seemed to be uninterested in any form of multi-byte characters.. just straightforward operation on bytes, even if they have the high bit set. That said, I appreciate the follow-up comments that dealt with the general problem. Thanks all, ..mark Sorry for dropping out of the thread. I lost interest in pursuing the issue once I learned that 'rev' would balk at any character it didn't like instead of just passing it through, and found a workaround for my case. What I really wanted is something that would do a byte-by-byte reversal working backwards from a LF character. My use for 'rev' is to allow sorting based on field position from the *end* of the line. 'sort' won't do this itself, as far as I can tell. My method follows: printf -v mySep '\xff' cat fileOfFullPathNames | rev | sed -r -e "s/\./$mySep/" | rev | sort -t "$mySep" --key=2.1 | tr "$mySep" '.' This particular pipe is to sort fileOfFullPathNames by file extension. As mentioned, this stops abruptly when it encounters my inserted field separator of \xff. I found that it would do what I wanted if I used \x1f as mySep instead. To be honest, in far too many years of using *nix as a user (not a developer), doing this kind of thing is the only use I've ever had for 'rev'. I probably used a different separator before (likely \x09) which is why I haven't encountered an issue. What I appear to really need is "rev --binary" that just reverses everything regardless of what it is until it finds a LF. I may get motivated to write it for myself if I run into situations where I can't work around the restrictions in 'rev'. As noted before in this thread, "rev --binary" is "LC_ALL=C rev". When 'rev' gets fixed, I'll try that. Until then, I'll just work around it as "LC_ALL=C rev" still dies when it encounters any byte =\x80. Well, it doesn't for me: > printf a'\x80'b | LC_ALL=C rev | od -t x1 000 62 80 61 -- 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: Is this correct behaviour for 'rev'?
On Sun, Nov 3, 2024 at 11:42 PM Thomas Wolff via Cygwin wrote: > Am 04.11.2024 um 05:56 schrieb Backwoods BC via Cygwin: > > On Sun, Nov 3, 2024 at 1:49 AM Mark Geisert via Cygwin > > wrote: > >> Continuing my monologue, with due consideration of comments posted, ... > >> > >> On 10/23/2024 10:01 PM, Mark Geisert via Cygwin wrote: > >>> Replying to myself, I continue... > >>> > >>> On 10/22/2024 10:33 PM, Mark Geisert via Cygwin wrote: > >>>> On 10/22/2024 8:00 PM, Backwoods BC via Cygwin wrote: > >>>>> It appears that 'rev' is choking on any character \x80 or higher, but > >>>>> is OK with those \x1f or smaller. It doesn't give an error or ignore > >>>>> it, it just stops. > >>>>> > >>>>> I don't have access to a Linux box so I can't see if this happens > >>>>> there and nothing in the documentation suggests that this is the > >>>>> correct functionality. > >>>>> > >>>>> Test case: > >>>>> printf 'no non-ASCII characters\nhex 01 >\x01< here\nhex 80 >\x80< > >>>>> here\nLine 4\n'|rev|rev > >>>>> > >>>>> This is for "rev from util-linux 2.33.1" > >>>>> > >>>>> I don't have the current version of 'rev' on my system due to not > >>>>> having updated in a while. I accidentally screwed up my installation > >>>>> and have been reluctant to wipe it and start over. > >>>>> > >>>>> So, is this the expected behaviour for the current version of 'rev' > >>>>> under Cygwin and/or Linux? > >>>> The current Cygwin util-linux 2.39.3-2 rev behaves in the same, broken > >>>> way. It looks like line-ending char(s) are not being handled > >>>> correctly. Don't know yet if it's rev itself or fgetws() being used > >>>> by rev that's busted. I'll investigate further. Thanks for the report! > >>> This is a locale issue. In the default Cygwin locale, rev mishandles > >>> the \x80 byte and instead of stopping with an error message it enters an > >>> infinite loop. I'll probably report this upstream instead of working > >>> out a local fix. > >> Upstream util-linux 2.40.2 has an updated 'rev' that stops with an error > >> message when the OP's testcase is tried. I'm testing the full 2.40.2 > >> for Cygwin release before too long. > >> > >>> There is a work-around: change to the "C" locale just to run rev. > >>> LC_ALL=C rev zzz > >>> where zzz is a file containing your four lines. You can also run your > >>> original testcase with "rev" replaced by "LC_ALL=C rev" in both places. > >> Implicit in that suggestion is that the OP seemed to be uninterested in > >> any form of multi-byte characters.. just straightforward operation on > >> bytes, even if they have the high bit set. > >> > >> That said, I appreciate the follow-up comments that dealt with the > >> general problem. > >> Thanks all, > >> > >> ..mark > > Sorry for dropping out of the thread. I lost interest in pursuing the > > issue once I learned that 'rev' would balk at any character it didn't > > like instead of just passing it through, and found a workaround for my > > case. What I really wanted is something that would do a byte-by-byte > > reversal working backwards from a LF character. > > > > My use for 'rev' is to allow sorting based on field position from the > > *end* of the line. 'sort' won't do this itself, as far as I can tell. > > My method follows: > > printf -v mySep '\xff' > > cat fileOfFullPathNames | rev | sed -r -e "s/\./$mySep/" | rev | sort > > -t "$mySep" --key=2.1 | tr "$mySep" '.' > > > > This particular pipe is to sort fileOfFullPathNames by file extension. > > As mentioned, this stops abruptly when it encounters my inserted field > > separator of \xff. I found that it would do what I wanted if I used > > \x1f as mySep instead. > > > > To be honest, in far too many years of using *nix as a user (not a > > developer), doing this kind of thing is the only use I've ever had for > > 'rev'. I probably used a different separator before (likely \x09) > > which is why I haven't encountered an issue. > > > > What I appear to really need is "rev --binary" that just reverses > > everything regardless of what it is until it finds a LF. I may get > > motivated to write it for myself if I run into situations where I > > can't work around the restrictions in 'rev'. > As noted before in this thread, "rev --binary" is "LC_ALL=C rev". When 'rev' gets fixed, I'll try that. Until then, I'll just work around it as "LC_ALL=C rev" still dies when it encounters any byte >=\x80. -- 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: libresolv does not provide __ns_initparse, resulting in LD undefined reference
On Nov 4 11:24, Corinna Vinschen via Cygwin wrote: > On Oct 29 22:35, Named T. Relay via Cygwin wrote: > > Hello, > > > > Today i installed cygwin to compile a windows .exe out of a Linux source > > program. > > While G++ on Linux compiles it correctly into a binary, on cygwin i got an > > issue during linking: > > > > $ g++ -O2 -Wall -Isrc -o bin/sealtool src/sign-verify.cpp -lcrypto > > -lssl -lcurl -lresolv > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x437): undefined reference to > > `__ns_initparse' > > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > > /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x49a): undefined reference to > > `__ns_parserr' > > collect2: error: ld returned 1 exit status > > > > >From looking at the nm results, the provided libresolv library does not > > >include these symbols. > > (But my linux distro's version of libresolv DOES have them!) > > > > Does anyone know why these symbols are missing? > > They have never been implemented in Cygwin itself. Cygwin only has a > piece of source called minires, a simple resolver lib depending on > the underlying Windows resolver, providing the res_FOO symbols from > resolv.h. The nameserver symbols from nameser.h are not part of the > Cywin core lib. Maybe you have more luck with the (unmaintained) > bind libs? But then again, if you use the bind libs, you have to maintain your own /etc/resolv.conf, since the bind libs don't call the Cygwin resolver and thus have no access to the OS resolver. Corinna -- 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: libresolv does not provide __ns_initparse, resulting in LD undefined reference
On Oct 29 22:35, Named T. Relay via Cygwin wrote: > Hello, > > Today i installed cygwin to compile a windows .exe out of a Linux source > program. > While G++ on Linux compiles it correctly into a binary, on cygwin i got an > issue during linking: > > $ g++ -O2 -Wall -Isrc -o bin/sealtool src/sign-verify.cpp -lcrypto > -lssl -lcurl -lresolv > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x437): undefined reference to > `__ns_initparse' > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x49a): undefined reference to > `__ns_parserr' > collect2: error: ld returned 1 exit status > > >From looking at the nm results, the provided libresolv library does not > >include these symbols. > (But my linux distro's version of libresolv DOES have them!) > > Does anyone know why these symbols are missing? They have never been implemented in Cygwin itself. Cygwin only has a piece of source called minires, a simple resolver lib depending on the underlying Windows resolver, providing the res_FOO symbols from resolv.h. The nameserver symbols from nameser.h are not part of the Cywin core lib. Maybe you have more luck with the (unmaintained) bind libs? Corinna -- 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
