[ITA] mhash
Sigh… some old and crusty files…. - x86 - 0.9.9.9-2 (source) from 2015-02-18 22:18 does not work... I pushed the fixed mhash https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=commitdiff;h=8e7f3a747287f0263bcd1316dedf7ea974914077 https://github.com/cygwin/scallywag/actions/runs/1447027874 While trying to package AIDE for x86, In file included from /usr/include/mhash.h:6, from /cygdrive/c/projects/aide/aide-0.17.3-1.i686/src/aide-0.17.3/include/db_config.h:87, from /cygdrive/c/projects/aide/aide-0.17.3-1.i686/src/aide-0.17.3/include/aide.h:27, from /cygdrive/c/projects/aide/aide-0.17.3-1.i686/src/aide-0.17.3/src/report.c:23: /usr/include/mutils/mincludes.h:82:10: fatal error: values.h: No such file or directory 82 | #include | ^~ compilation terminated. make[1]: *** [Makefile:739: src/report.o] Error 1 make[1]: Leaving directory '/cygdrive/c/projects/aide/aide-0.17.3-1.i686/build' make: *** [Makefile:510: all] Error 2 *** ERROR: make failed So it looks like the x86 build and package of mhash found a windows development kit on the path… Rebuilding and repackaging it allows >>> Checking packages for unexpected, missing or duplicate files >>> Creating source patches include/util.h |1 + 1 file changed, 1 insertion(+) >>> Creating source package aide-0.17.3-1.src/ aide-0.17.3-1.src/aide-0.17.3-1.src.patch aide-0.17.3-1.src/aide-0.17.3.tar.gz aide-0.17.3-1.src/aide-0.17.3.tar.gz.asc aide-0.17.3-1.src/aide.cygport >>> aide requires: cygwin libmhash2 libpcre1 zlib0 cygwin libmhash2 libpcre1 >>> zlib0
Re: Another pipe-related problem?
Greetings, Henry S. Thompson! >> ... >> The main change was that we stopped using Win32 Overlapped I/O >> (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) >> and switched to using the NT API. As a result, pipe I/O became much >> more efficient. It wouldn't surprise me if the efficiency alone is >> what exposed the bug. >> >> The good news is that the bug doesn't seem to occur in XEmacs 21.4 >> (on 32-bit Cygwin). So one way to approach this would be to bisect >> the XEmacs git repo to find the commit that introduced the bug. >> You'd probably have to do the work on 32-bit Cygwin since, if I >> remember correctly, XEmacs 21.4 didn't build on 64-bit Cygwin. > Right, although I _suspect_ it will be in 64-bit-only code. Easy > enough to find out, once I resurrect a 32-bit install on a spare > machine that I can run 3.3 on (I use XEmacs all day every day from my > day job, so I need to stay with 3.2 until we fix this). > So, this may take a while, unless someone else hits the problem and > finds a simpler test case. You can install as many Cygwin setups as you need on the same machine. They are not stepping on each other toes. Though I strongly require a virtual machine for such exercises. -- With best regards, Andrey Repin Thursday, November 11, 2021 2:06:01 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: [PATCH 0/2] Fix a bad case of absolute path handling
On 11/10/2021 3:32 PM, corinna-cyg...@cygwin.com wrote: From: Corinna Vinschen As I told Takashi in PM, I will try to more often send patches to the cygwin-patches ML before pushing them, so there's a chance to chime in. LGTM. This patch series is supposed to address the `rm -rf' problem reported in https://cygwin.com/pipermail/cygwin/2021-November/249837.html It was always frustrating, having to allow DOS drive letter paths for backward compatibility. This here is another case of ambiguity, triggered by the `isabspath' macro handling "X:" as absolute path, even without the trailing slash or backslash. Check out the 2nd patch for a more detailed description. While at it, I wonder if we might have a chance to fix these ambiguities in a better way. For instance, consider this: $ mkdir -p test/c: $ cd test As non-admin: $ touch c:/foo touch: cannot touch 'c:/foo': Permission denied As admin, even worse: $ touch c:/foo $ ls /cygdrive/c/foo foo As long as we support DOS paths as input, I have a hard time to see how to fix this, but maybe we can at least minimize the ambiguity somehow. I can't immediately think of anything. But is it really impossible to phase out DOS path support over a period of time? We could start with a HEADS-UP, asking for comments, then a deprecation announcement, then something like the old dosfilewarning option, then a more forceful warning that can't be turned off, and finally removal of support. This could be done over a period of several years (not sure how many). We could also put lines like # C:/ on /c type ntfs (binary,posix=0) into the default /etc/fstab. Ken
Re: Could rm remove files and folders with colon in their name?
On Nov 10 21:24, Mario Emmenlauer wrote: > On 10.11.21 14:49, Corinna Vinschen via Cygwin wrote: > > On Nov 10 10:45, Mario Emmenlauer wrote: > >> Could 'rm' support removing files and folders that have a colon ':' in > >> their name? I.e. I would like that 'rm -fr' would remove a full directory > >> tree, including such folders. Currently it will correctly remove anything > >> inside such folders, but not the folder itself. > >> > >> As an example, for the following structure: > >> C:/root/folder/C:/inside/file.txt > >> > >> When using 'rm -fr root', afterwards I have: > >> C:/root/folder/C: > > > > It works fine if the folder is called, say, "a:b", it just doesn't > > work for a name which looks like a drive letter "x:", apparently. > > That is indeed interesting, I was not aware of it! Then maybe the > problem is not so hard to solve? That would be awesome! To the contrary. The problem is the ambiguity that "X:/foo" might be either the absolute POSIX path $CWD/X:/foo, or the absolute DOS path "X:\foo". I have a patch which fixes your case, but not much else. The problem is that we historically allow DOS paths as input at all. That was a bad decision from the start, but you can't easily change 25 years of history... 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
[PATCH 2/2] Cygwin: introduce isabspath_strict macro
From: Corinna Vinschen
isabspath handles a path "X:", without trailing slas or backslash,
as absolute path. This breaks some scenarios with relative paths
starting with "X:". For instance, fstatat will mishandle a call
with valid dirfd and "c:" as path.
The reason is that gen_full_path_at() will check for isabspath("C:")
which returns true. So the path will be used verbatim in fstatat,
rather than being converted to a path "/c:".
So, introduce isabspath_strict, which returns true for paths starting
with "X:" only if the next char is actually a slash or backslash.
Use it from gen_full_path_at().
This still fixes only half the problem. The right thing would have been
to disallow using DOS paths in the first place. Unfortunately it's much
too late for that.
Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249837.html
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/syscalls.cc | 2 +-
winsup/cygwin/winsup.h| 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 7a48e422e8f4..661c143479e4 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -4714,7 +4714,7 @@ gen_full_path_at (char *path_ret, int dirfd, const char
*pathname,
return -1;
}
}
- if (pathname && isabspath (pathname))
+ if (pathname && isabspath_strict (pathname))
stpcpy (path_ret, pathname);
else
{
diff --git a/winsup/cygwin/winsup.h b/winsup/cygwin/winsup.h
index f6fea6313d56..1f265ec28934 100644
--- a/winsup/cygwin/winsup.h
+++ b/winsup/cygwin/winsup.h
@@ -139,9 +139,17 @@ extern int cygserver_running;
#undef issep
#define issep(ch) (strchr (" \t\n\r", (ch)) != NULL)
+/* Treats "X:" as absolute path.
+ FIXME: We should drop the notion that "X:" is a valid absolute path.
+ Only "X:/" and "X:\\" should be (see isabspath_strict below). The
+ problem is to find out if we have code depending on this behaviour. */
#define isabspath(p) \
(isdirsep (*(p)) || (isalpha (*(p)) && (p)[1] == ':' && (!(p)[2] || isdirsep
((p)[2]
+/* Treats "X:/" and "X:\\" as absolute paths, but not "X:" */
+#define isabspath_strict(p) \
+ (isdirsep (*(p)) || (isalpha (*(p)) && (p)[1] == ':' && isdirsep ((p)[2])))
+
/ Initialization/Termination **/
class per_process;
--
2.31.1
[PATCH 0/2] Fix a bad case of absolute path handling
From: Corinna Vinschen As I told Takashi in PM, I will try to more often send patches to the cygwin-patches ML before pushing them, so there's a chance to chime in. This patch series is supposed to address the `rm -rf' problem reported in https://cygwin.com/pipermail/cygwin/2021-November/249837.html It was always frustrating, having to allow DOS drive letter paths for backward compatibility. This here is another case of ambiguity, triggered by the `isabspath' macro handling "X:" as absolute path, even without the trailing slash or backslash. Check out the 2nd patch for a more detailed description. While at it, I wonder if we might have a chance to fix these ambiguities in a better way. For instance, consider this: $ mkdir -p test/c: $ cd test As non-admin: $ touch c:/foo touch: cannot touch 'c:/foo': Permission denied As admin, even worse: $ touch c:/foo $ ls /cygdrive/c/foo foo As long as we support DOS paths as input, I have a hard time to see how to fix this, but maybe we can at least minimize the ambiguity somehow. Corinna Corinna Vinschen (2): Cygwin: drop unused isabspath_u and iswabspath macros Cygwin: introduce isabspath_strict macro winsup/cygwin/syscalls.cc | 2 +- winsup/cygwin/winsup.h| 20 2 files changed, 9 insertions(+), 13 deletions(-) -- 2.31.1
[PATCH 1/2] Cygwin: drop unused isabspath_u and iswabspath macros
From: Corinna Vinschen
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/winsup.h | 12
1 file changed, 12 deletions(-)
diff --git a/winsup/cygwin/winsup.h b/winsup/cygwin/winsup.h
index abdef35261ca..f6fea6313d56 100644
--- a/winsup/cygwin/winsup.h
+++ b/winsup/cygwin/winsup.h
@@ -139,18 +139,6 @@ extern int cygserver_running;
#undef issep
#define issep(ch) (strchr (" \t\n\r", (ch)) != NULL)
-/* Every path beginning with / or \, as well as every path being X:
- or starting with X:/ or X:\ */
-#define isabspath_u(p) \
- ((p)->Length && \
- (iswdirsep ((p)->Buffer[0]) || \
-((p)->Length > sizeof (WCHAR) && iswalpha ((p)->Buffer[0]) \
-&& (p)->Buffer[1] == L':' && \
-((p)->Length == 2 * sizeof (WCHAR) || iswdirsep ((p)->Buffer[2])
-
-#define iswabspath(p) \
- (iswdirsep (*(p)) || (iswalpha (*(p)) && (p)[1] == L':' && (!(p)[2] ||
iswdirsep ((p)[2]
-
#define isabspath(p) \
(isdirsep (*(p)) || (isalpha (*(p)) && (p)[1] == ':' && (!(p)[2] || isdirsep
((p)[2]
--
2.31.1
Re: New pipe code means a gold star is merited
On 11/10/2021 1:45 PM, Henry S. Thompson via Cygwin wrote: for Ken Brown and Takashi Yano, don't you think? Even though we made XEmacs unusable?!? :) But seriously, it was a joint effort among the two of us and Corinna. Thanks. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Could rm remove files and folders with colon in their name?
On 10.11.21 14:49, Corinna Vinschen via Cygwin wrote: > On Nov 10 10:45, Mario Emmenlauer wrote: >> Could 'rm' support removing files and folders that have a colon ':' in >> their name? I.e. I would like that 'rm -fr' would remove a full directory >> tree, including such folders. Currently it will correctly remove anything >> inside such folders, but not the folder itself. >> >> As an example, for the following structure: >> C:/root/folder/C:/inside/file.txt >> >> When using 'rm -fr root', afterwards I have: >> C:/root/folder/C: > > It works fine if the folder is called, say, "a:b", it just doesn't > work for a name which looks like a drive letter "x:", apparently. That is indeed interesting, I was not aware of it! Then maybe the problem is not so hard to solve? That would be awesome! > Funny. I'm busy with non-Cygwin stuff ATM, but I'll look into it > later. > > Thanks for the report. Thanks a lot for your support! All the best, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 München http://www.biodataanalysis.de/ -- 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: Could rm remove files and folders with colon in their name?
Hi Brian, On 10.11.21 17:35, Brian Inglis wrote: > On 2021-11-10 02:45, Mario Emmenlauer wrote: >> PS: These folders are created when I use the Cygwin-based build system >> for ICU (see >> https://unicode-org.github.io/icu/userguide/icu4c/build.html#how-to-build-and-install-on-windows-with-cygwin) >> For me this is in a combination with native Perl for Windows (ActivePerl, >> in my case), and using absolute build paths. After using ICU's build >> system, I can not remove the build tree anymore. It may be possible to >> solve this on the ICU side too. But their automake-and-Perl-based path >> mangling is not easily modified, and I've failed to isolate the root >> cause of the illegal paths. > > Install the Cygwin cygport and libicu-devel source and binary packages and > use only Cygwin exclusively with cygport to avoid problems. I'm not sure that this is what I want. I want to build ICU with Visual Studio and the ClangCl compiler frontend from LLVM 13.0.0. Their build system can use Cygwin for this combination to orchestrate and configure the build - which I very much like :-) Sorry that I did not mention this in my email. The build works fine and I get native ICU shared libraries like I want. The only "downside" is that it creates the unsupported folders :-) Cheers, Mario -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 München http://www.biodataanalysis.de/ -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mintty 3.5.2
I have uploaded mintty 3.5.2 with the following changes: Unicode and Emoji data * Unicode 14.0 update. Terminal features * Fix (revert back) DECSDM (DECSET 80) Sixel Display mode (#1127, xterm 369). * Sound file playing OSC 440 (#1122). * DECPS tone playing support (#1122). * Fixed LED state glitch when ScrollLock is held in auto-repeat. * Extended scope of area attributes change functions DECCARA and DECRARA. * Unscroll sequence CSI +T, filling lines from scrollback buffer (kitty). * Changed default BracketedPasteByLine=0 for consistent appearance. Window handling * Fixed -s max... options (#1124). * Tweaked handling of positioning and size options. * Always support negative position offset (#1123). * Avoid position gap after Options Apply (#1126). * Copy text: set proper clipboard timestamp. The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: mintty 3.5.2
I have uploaded mintty 3.5.2 with the following changes: Unicode and Emoji data * Unicode 14.0 update. Terminal features * Fix (revert back) DECSDM (DECSET 80) Sixel Display mode (#1127, xterm 369). * Sound file playing OSC 440 (#1122). * DECPS tone playing support (#1122). * Fixed LED state glitch when ScrollLock is held in auto-repeat. * Extended scope of area attributes change functions DECCARA and DECRARA. * Unscroll sequence CSI +T, filling lines from scrollback buffer (kitty). * Changed default BracketedPasteByLine=0 for consistent appearance. Window handling * Fixed -s max... options (#1124). * Tweaked handling of positioning and size options. * Always support negative position offset (#1123). * Avoid position gap after Options Apply (#1126). * Copy text: set proper clipboard timestamp. The homepage is at http://mintty.github.io/ It also links to the issue tracker. -- Thomas
New pipe code means a gold star is merited
for Ken Brown and Takashi Yano, don't you think? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- 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: Another pipe-related problem?
Ken Brown writes: > ... > The main change was that we stopped using Win32 Overlapped I/O > (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) > and switched to using the NT API. As a result, pipe I/O became much > more efficient. It wouldn't surprise me if the efficiency alone is > what exposed the bug. > > The good news is that the bug doesn't seem to occur in XEmacs 21.4 > (on 32-bit Cygwin). So one way to approach this would be to bisect > the XEmacs git repo to find the commit that introduced the bug. > You'd probably have to do the work on 32-bit Cygwin since, if I > remember correctly, XEmacs 21.4 didn't build on 64-bit Cygwin. Right, although I _suspect_ it will be in 64-bit-only code. Easy enough to find out, once I resurrect a 32-bit install on a spare machine that I can run 3.3 on (I use XEmacs all day every day from my day job, so I need to stay with 3.2 until we fix this). So, this may take a while, unless someone else hits the problem and finds a simpler test case. Thanks again, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [cygwin] Re: Problem with ssh(d)
> -Original Message- > From: Bill Stewart > Sent: Wednesday, November 10, 2021 10:44 AM > > On Wed, Nov 10, 2021 at 8:28 AM Strasser, Dominik (DI SW ICS ICV) wrote: > > I know that this is the standard installation. But we absolutely need > > passwordless login. So this was the workaround we found. > > The number of groups differs when sshd is run as local system, and when > > authorized_keys exist or not. Groups are OK, when it is run under the one > > user we absolutely need the passwordless login. > > > > Password-less logon is supported when running as local system. I do this > all the time, so there must be something that is not correct about your > configuration. > > Sorry, don't know what that might be. I slightly misread the email. To be clear password less login works - BUT as I said MS design choices result in a different security token being issues without password vs with password. As such your ability to access certain resources are limited. Enumerate the groups you have as PKI authentication then bless those groups to perform the action needed. -Jason -- Jason Pyeron | Architect PD Inc| Certified SBA 8(a) 10 w 24th St | Certified SBA HUBZone Baltimore, MD | CAGE Code: 1WVR6 .mil: jason.j.pyeron@mail.mil .com: jpye...@pdinc.us tel : 202-741-9397 -- 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: playground procedures and docs
> -Original Message- > From: Jason Pyeron > Sent: Wednesday, November 10, 2021 12:57 PM > > > Sent: Wednesday, November 10, 2021 11:25 AM > > That is why it is a good idea to checkout your repo on a playground > > branch, then force push your repo to: > > > > ssh://cyg...@cygwin.com/git/cygwin-packages/playground > > > > and post the jobs.cgi, run, and log links. > > I could not seem to find pages or mailing list archives on the jobs.cgi / run > / log items. https://www.cygwin.com/packaging/build.html Do not know, why I did not see: Package build service (experimental) After pushing to a package git repository, an automatic build of the package is queued: remote: scallywag: build queued remote: scallywag: https://cygwin.com/cgi-bin2/jobs.cgi?id= The results will appear (some time later) at https://cygwin.com/cgi-bin2/jobs.cgi (URL subject to change). -Jason
Re: Another pipe-related problem?
On 11/10/2021 12:23 PM, Henry S. Thompson wrote: Ken Brown via Cygwin writes: On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote: Back to the drawing board. It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read and instead see if something is in fact repeatedly writing to the pipe, so that drain_signal_event_pipe never finishes. Putting a breakpoint at fhandler_pipe::raw_write, I found that this is in fact the case. While the main thread is repeatedly reading from the pipe, a second thread is repeatedly writing to it. Here's the backtrace of that thread: Argh. Thanks for the hard labour on this. This is not a part of the XEmacs code I have any experience of. Is there any clue you can give about how things changed in all the September commits to fhandler_pipe.cc that might have exposed the XEmacs bug? The main change was that we stopped using Win32 Overlapped I/O (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) and switched to using the NT API. As a result, pipe I/O became much more efficient. It wouldn't surprise me if the efficiency alone is what exposed the bug. The good news is that the bug doesn't seem to occur in XEmacs 21.4 (on 32-bit Cygwin). So one way to approach this would be to bisect the XEmacs git repo to find the commit that introduced the bug. You'd probably have to do the work on 32-bit Cygwin since, if I remember correctly, XEmacs 21.4 didn't build on 64-bit Cygwin. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
playground procedures and docs
> Sent: Wednesday, November 10, 2021 11:25 AM > That is why it is a good idea to checkout your repo on a playground > branch, then force push your repo to: > > ssh://cyg...@cygwin.com/git/cygwin-packages/playground > > and post the jobs.cgi, run, and log links. I could not seem to find pages or mailing list archives on the jobs.cgi / run / log items. Sorry, if I am obtuse. v/r, Jason Pyeron -- Jason Pyeron | Architect PD Inc| Certified SBA 8(a) 10 w 24th St | Certified SBA HUBZone Baltimore, MD | CAGE Code: 1WVR6 .mil: jason.j.pyeron@mail.mil .com: jpye...@pdinc.us tel : 202-741-9397
Re: Another pipe-related problem?
Ken Brown via Cygwin writes: > On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote: >> Back to the drawing board. > > It finally occurred to me to stop looking for a bug in > fhandler_pipe::raw_read and instead see if something is in fact > repeatedly writing to the pipe, so that drain_signal_event_pipe > never finishes. Putting a breakpoint at fhandler_pipe::raw_write, I > found that this is in fact the case. While the main thread is > repeatedly reading from the pipe, a second thread is repeatedly > writing to it. Here's the backtrace of that thread: Argh. Thanks for the hard labour on this. This is not a part of the XEmacs code I have any experience of. Is there any clue you can give about how things changed in all the September commits to fhandler_pipe.cc that might have exposed the XEmacs bug? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- 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: Could rm remove files and folders with colon in their name?
On 2021-11-10 02:45, Mario Emmenlauer wrote:
Dear All,
I've searched if this topic has come up before but could not find it.
Could 'rm' support removing files and folders that have a colon ':' in
their name? I.e. I would like that 'rm -fr' would remove a full directory
tree, including such folders. Currently it will correctly remove anything
inside such folders, but not the folder itself.
As an example, for the following structure:
C:/root/folder/C:/inside/file.txt
When using 'rm -fr root', afterwards I have:
C:/root/folder/C:
To remove everything, I can use 'find root -depth -exec rmdir \{\} \;'
I understand that files and folders with colon in their name are illegal
on Windows and not supported very well. But a number of tools manage to
create (and also remove) such files. I've found that even the native
'del' can support this when using the UNC name (see for example
https://serverfault.com/a/96833). It would be great if Cygwin could
also feature this support.
PS: These folders are created when I use the Cygwin-based build system
for ICU (see
https://unicode-org.github.io/icu/userguide/icu4c/build.html#how-to-build-and-install-on-windows-with-cygwin)
For me this is in a combination with native Perl for Windows (ActivePerl,
in my case), and using absolute build paths. After using ICU's build
system, I can not remove the build tree anymore. It may be possible to
solve this on the ICU side too. But their automake-and-Perl-based path
mangling is not easily modified, and I've failed to isolate the root
cause of the illegal paths.
Install the Cygwin cygport and libicu-devel source and binary packages
and use only Cygwin exclusively with cygport to avoid problems.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] aide 0.17.3
On 2021-11-10 05:33, Jason Pyeron wrote:
On Sunday, October 31, 2021 10:37 AM, Jason Pyeron wrote:
On Sunday, October 31, 2021 8:48 AM, Jon Turney wrote:
On 29/09/2021 15:27, Jason Pyeron wrote:
On Friday, July 30, 2021 10:34 AM, Jason Pyeron wrote:
AIDE - Advanced Intrusion Detection Environment
https://github.com/aide/aide/
It is a GPL v2 tool for monitoring file system changes.
There was no (mature?) Windows open source solution until AIDE was built and
tested for
Cygwin. This fills a long standing gap in needs.
Closed source alternative - Trip Wire.
It is packaged and shipped with most Linux distributions - I am most familiar
with the
RHEL packaging.
I have built and tested the most recent stable and development versions.
I will track the development versions for test package releases.
Category Security.
Thoughts?
There has been no response. It has been in test locally for 2
months now.
May I push the cygport to git and provide a test release?
Upstream has expressed willingness to review/track patches, if
needed.
Good idea to submit patches upstream, as it reduces the number of
patches you have to maintain and rebase, and they may have a better idea
of how to achieve the same goal with more generality having their
knowledge of the package source and build.
Thanks for offering to package and maintain this package, and
apologies for the delay in responding.
Notwithstanding [1] (which needs updating), I look for 2 things
in an ITP: - a statement that the software uses an acceptable
open-source license
GPL v2, mentioned in the above original email.
- the cygport file (as an attachemnt or link) so it can be
reviewed and tested
The attached (with required patch) has been in testing on multiple
windows servers since late July. They can also be reviewed on
github [2].
Using github is an issue for some: gitlab, bitbucket, etc. may or may
not be.
That is why it is a good idea to checkout your repo on a playground
branch, then force push your repo to:
ssh://cyg...@cygwin.com/git/cygwin-packages/playground
and post the jobs.cgi, run, and log links.
You may also add this as another remote e.g. playground to your repo in
your .git/config e.g.:
[remote "playground"]
url = ssh://cyg...@cygwin.com/git/cygwin-packages/playground
fetch = +refs/heads/playground:refs/remotes/playground/*
[branch "playground"]
remote = playground
merge = refs/heads/playground
or equivalent using commands (that I never learned about).
Or copy your cygport, patches, source and both arch build hints and
tarballs, including debuginfo if generated, to a storage site folder,
and post the access link.
If you're still interested in progressing this, please provide the
cygport file for discussion.
[1] https://cygwin.com/packaging-contributors-guide.html#submitting
Interested, very interested. I am on the aide developers list to track updates,
bugs, and
patches.
2: https://github.com/pdinc-oss/aide/tree/cygport
Anyone interested in reviewing? Can I put this out there as a test
package - there are many not on this mailing list that would test but
would not build it.
You should be able to drop the explicit REQUIRES. You only need to
specify those not directly used by the executables, as cygport figures
those out and reports them at the end of your build. You should be
seeing those package names duplicated at the end of your cygport ...
{package,pkg,{,almost}all}{,-test} run e.g.:
>>> aide requires: cygwin libmhash2 libpcre1 zlib0 cygwin libmhash2
libpcre1 zlib0
Please also ensure that the package builds cleanly on both arches.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
Re: Problem with ssh(d)
On Wed, Nov 10, 2021 at 8:28 AM Strasser, Dominik (DI SW ICS ICV) wrote: I know that this is the standard installation. But we absolutely need > passwordless login. So this was the workaround we found. > The number of groups differs when sshd is run as local system, and when > authorized_keys exist or not. Groups are OK, when it is run under the one > user we absolutely need the passwordless login. > Password-less logon is supported when running as local system. I do this all the time, so there must be something that is not correct about your configuration. Sorry, don't know what that might be. Bill -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Console output broken in version 3.3.x under native ninja
Hi: This worked fine with Cygwin 3.2.0 but is broken starting with Cygwin 3.3.0, hence I think it is a Cygwin bug and not a ninja bug. When running Cygwin applications under Windows native 'ninja.exe' build tool (not the Cygwin packaged one) then the stdout is not emitted to the console starting with Cygwin 3.3.0. It worked fine with Cygwin 3.2.0 and stdout is emitted to the console. If using Cygwin ninja with 3.3.0 it also works. The problem is with Windows native ninja and Cygwin programs with Cygwin version 3.3.0 and later. Using Cygwin ninja is not an option for us as a solution. We need to use the Windows native ninja for reasons that I won't go into here. To reproduce the issue: 1) Download windows native ninja from here: https://github.com/ninja-build/ninja/releases a. Use ninja-win.zip that has the ninja.exe executable b. DO NOT USE the Cygwin version of ninja 2) Below is a sample build.ninja file that demonstrates the problem. This sample build.ninja simply causes bash -help to run. Create this build.ninja text file in some directory. 3) cd to the directory where you have the build.ninja, and then run the native ninja.exe, you won't see the bash --help output with Cygwin 3.3.0 and later. a. I suggesting using -v option with ninja.exe: "path/to/native/ninja.exe -v" 4) If you try it with Cygwin 3.2.0 it works fine you will see the bash --help output. 5) If you run c:/cygwin64/bin/bash --help outside of ninja it works fine. 6) This happens if you run the native ninja.exe from either a command window or from the Cygwin/minty/bash Here is the sample build.ninja to be used to reproduce the problem: start build.ninja -- rule CUSTOM_COMMAND command = $COMMAND description = $DESC build MC5U_BMDCO6_versions.txt: CUSTOM_COMMAND COMMAND = c:/cygwin64/bin/bash --help DESC = Running bash --help restat = 1 end build.ninja -- Thanks for having a look. Regards, Rob Bresalier -- 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: Problem with ssh(d)
Hi Bill, On 10.11.2021 16:10, Bill Stewart wrote: On Wed, Nov 10, 2021 at 7:52 AM Strasser, Dominik (DI SW ICS ICV) wrote: We are in an AD environment. AD holds the needed data for ssh(d) to work. I can log into cygwin using ssh. But if I have a key stored .ssh/authorized_keys for passwordless login, the groups my user is in differs from the one w/o an authorized keys. Unfortunately exactly the group(s) for accessing the shared filesystems is missing. We were investigating a lot and the only workaround we found is that the sshd service runs under the user we want to log in. This unfortunately disables any other user to log into the cygwin machine. When debugging ssh with -vvv, there is no visible difference between the login with authorized_keys or without (of course there is a difference wrt. the login method). The OpenSSH server service should be running as local system, not as a specific user. I know that this is the standard installation. But we absolutely need passwordless login. So this was the workaround we found. The number of groups differs when sshd is run as local system, and when authorized_keys exist or not. Groups are OK, when it is run under the one user we absolutely need the passwordless login. Regards Dominik Bill -- Dominik Strasser | Phone: +49 89 99013-436 OneSpin Solutions GmbH | Fax:+49 89 99013-100 Nymphenburgerstr. 20a 80335 Muenchen |dominik.stras...@onespin.com OneSpin Solutions GmbH A Siemens business Geschaeftsfuehrung: Thomas Heurung, Frank Thurauf Sitz: Muenchen; Amtsgericht Muenchen HRB 139 464 UstID#: DE 814 413 215 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [cygwin] Problem with ssh(d)
> -Original Message- > From: Strasser, Dominik (DI SW ICS ICV) > Sent: Wednesday, November 10, 2021 9:50 AM > > Hi all, > I am facing the following problem with my sshd installation. > > We are in an AD environment. AD holds the needed data for ssh(d) to > work. I can log into cygwin using ssh. But if I have a key stored > .ssh/authorized_keys for passwordless login, the groups my user is in > differs from the one w/o an authorized keys. Unfortunately exactly the > group(s) for accessing the shared filesystems is missing. We were > investigating a lot and the only workaround we found is that the sshd > service runs under the user we want to log in. This unfortunately > disables any other user to log into the cygwin machine. When debugging > ssh with -vvv, there is no visible difference between the login with > authorized_keys or without (of course there is a difference wrt. the > login method). > > This is cygwin 3.2.0 and openssh openssh-8.8p1-1. > > Any clues ? Passwordless login and network shares are incompatible by Microsoft design. You can see this in Microsoft task scheduler as well. Our solution is to not rely on network file sharing, as it is disabled in our environment anyway due to security issues. v/r, Jason Pyeron -- Jason Pyeron | Architect PD Inc| Certified SBA 8(a) 10 w 24th St | Certified SBA HUBZone Baltimore, MD | CAGE Code: 1WVR6 .mil: jason.j.pyeron@mail.mil .com: jpye...@pdinc.us tel : 202-741-9397 -- 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
Problem with ssh(d)
Hi all, I am facing the following problem with my sshd installation. We are in an AD environment. AD holds the needed data for ssh(d) to work. I can log into cygwin using ssh. But if I have a key stored .ssh/authorized_keys for passwordless login, the groups my user is in differs from the one w/o an authorized keys. Unfortunately exactly the group(s) for accessing the shared filesystems is missing. We were investigating a lot and the only workaround we found is that the sshd service runs under the user we want to log in. This unfortunately disables any other user to log into the cygwin machine. When debugging ssh with -vvv, there is no visible difference between the login with authorized_keys or without (of course there is a difference wrt. the login method). This is cygwin 3.2.0 and openssh openssh-8.8p1-1. Any clues ? Best regards Dominik -- Dominik Strasser | Phone: +49 89 99013-436 OneSpin Solutions GmbH | Fax:+49 89 99013-100 Nymphenburgerstr. 20a 80335 Muenchen | dominik.stras...@onespin.com OneSpin Solutions GmbH A Siemens business Geschaeftsfuehrung: Thomas Heurung, Frank Thurauf Sitz: Muenchen; Amtsgericht Muenchen HRB 139 464 UstID#: DE 814 413 215 -- 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: Could rm remove files and folders with colon in their name?
Greetings, Mario Emmenlauer!
> Dear All,
> I've searched if this topic has come up before but could not find it.
> Could 'rm' support removing files and folders that have a colon ':' in
> their name? I.e. I would like that 'rm -fr' would remove a full directory
> tree, including such folders. Currently it will correctly remove anything
> inside such folders, but not the folder itself.
> As an example, for the following structure:
> C:/root/folder/C:/inside/file.txt
> When using 'rm -fr root', afterwards I have:
> C:/root/folder/C:
> To remove everything, I can use 'find root -depth -exec rmdir \{\} \;'
> I understand that files and folders with colon in their name are illegal
> on Windows and not supported very well.
They are not necessarily illegal, it's just not well supported.
> But a number of tools manage to create (and also remove) such files. I've
> found that even the native 'del' can support this when using the UNC name
> (see for example https://serverfault.com/a/96833). It would be great if
> Cygwin could also feature this support.
> PS: These folders are created when I use the Cygwin-based build system
> for ICU (see
> https://unicode-org.github.io/icu/userguide/icu4c/build.html#how-to-build-and-install-on-windows-with-cygwin)
> For me this is in a combination with native Perl for Windows (ActivePerl,
> in my case), and using absolute build paths. After using ICU's build
> system, I can not remove the build tree anymore. It may be possible to
> solve this on the ICU side too. But their automake-and-Perl-based path
> mangling is not easily modified, and I've failed to isolate the root
> cause of the illegal paths.
Mixing Cygwin and native tools like that is prone to cause issues. In your
case, it may be more than one issue, as build system could misdetect the
platform it is building on, and such unusable paths could be the least of your
issues.
--
With best regards,
Andrey Repin
Wednesday, November 10, 2021 17:45:57
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: Another pipe-related problem?
On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote:
Back to the drawing board.
It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read
and instead see if something is in fact repeatedly writing to the pipe, so that
drain_signal_event_pipe never finishes. Putting a breakpoint at
fhandler_pipe::raw_write, I found that this is in fact the case. While the main
thread is repeatedly reading from the pipe, a second thread is repeatedly
writing to it. Here's the backtrace of that thread:
#0 fhandler_pipe_fifo::raw_write (this=0x18039f370, ptr=0x2c4ca3b, len=1)
at ../../../../temp/winsup/cygwin/fhandler_pipe.cc:430
#1 0x00018006f39a in fhandler_base::write (this=0x18039f370,
ptr=0x2c4ca3b, len=1) at ../../../../temp/winsup/cygwin/fhandler.cc:907
#2 0x000180158fd1 in write (fd=4, ptr=0x2c4ca3b, len=1)
at ../../../../temp/winsup/cygwin/syscalls.cc:1360
#3 0x0001801b9b5b in _sigfe () at sigfe.s:35
#4 0x0001006ae471 in retry_write_1 (fildes=4, buf=0x2c4ca3b, nbyte=1,
allow_quit=0) at sysdep.c:2364
#5 0x0001006ae581 in retry_write (fildes=4, buf=0x2c4ca3b, nbyte=1)
at sysdep.c:2386
#6 0x0001004b3ba5 in signal_fake_event () at event-unixoid.c:149
#7 0x000100691060 in alarm_signal (signo=14) at signal.c:559
#8 0x0001006ec6e4 in mswindows_raise (nsig=14) at win32.c:694
#9 0x0001006ec72d in setitimer_helper_proc (unused_uID=96, unused_uMsg=0,
dwUser=14, unused_dw1=0, unused_dw2=0) at win32.c:742
#10 0x7ffb363c2811 in WINMM!PlaySoundW () from /c/WINDOWS/SYSTEM32/WINMM.dll
#11 0x00018004771c in _cygtls::call2 (this=0x2c4ce00,
func=0x7ffb363c26c0 , arg=0x0, buf=0x2c4cce0)
at ../../../../temp/winsup/cygwin/cygtls.cc:40
#12 0x0001800476c1 in _cygtls::call (
func=0x7ffb363c26c0 , arg=0x0)
at ../../../../temp/winsup/cygwin/cygtls.cc:27
#13 0x0001800e4f15 in threadfunc_fe (arg=0x0)
at ../../../../temp/winsup/cygwin/init.cc:28
#14 0x7ffb43da7034 in KERNEL32!BaseThreadInitThunk ()
from /c/WINDOWS/System32/KERNEL32.DLL
#15 0x7ffb448c2651 in ntdll!RtlUserThreadStart ()
from /c/WINDOWS/SYSTEM32/ntdll.dll
#16 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
This looks to me like an XEmacs bug that happens to be triggered by the new pipe
code, although maybe there's also a Cygwin bug that I'm not seeing. The comment
at the beginning of signal_fake_event might be relevant:
void
signal_fake_event (void)
{
Rawbyte rbyte = 0;
/* We do the write always. Formerly I tried to "optimize" this
by setting a flag indicating whether we're blocking and only
doing the write in that case, but there is a race condition
if the signal occurs after we've checked for the signal
occurrence (which could occur in many places throughout
an iteration of the command loop, e.g. in status_notify()),
but before we set the blocking flag.
This should be OK as long as write() is reentrant, which I'm fairly
sure it is since it's a system call. */
if (signal_event_pipe_initialized)
/* In case a signal comes through while we're dumping */
{
int old_errno = errno;
retry_write (signal_event_pipe[1], , 1);
errno = old_errno;
}
}
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Could rm remove files and folders with colon in their name?
On Nov 10 10:45, Mario Emmenlauer wrote: > > Dear All, > > I've searched if this topic has come up before but could not find it. > > Could 'rm' support removing files and folders that have a colon ':' in > their name? I.e. I would like that 'rm -fr' would remove a full directory > tree, including such folders. Currently it will correctly remove anything > inside such folders, but not the folder itself. > > As an example, for the following structure: > C:/root/folder/C:/inside/file.txt > > When using 'rm -fr root', afterwards I have: > C:/root/folder/C: It works fine if the folder is called, say, "a:b", it just doesn't work for a name which looks like a drive letter "x:", apparently. Funny. I'm busy with non-Cygwin stuff ATM, but I'll look into it later. Thanks for the report. 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: [ITP] aide 0.17.3
> -Original Message- > From: Jason Pyeron > Sent: Sunday, October 31, 2021 10:37 AM > > > -Original Message- > > From: Jon Turney > > Sent: Sunday, October 31, 2021 8:48 AM > > > > On 29/09/2021 15:27, Jason Pyeron wrote: > > >> -Original Message- > > >> From: Jason Pyeron > > >> Sent: Friday, July 30, 2021 10:34 AM > > >> > > >> AIDE - Advanced Intrusion Detection Environment > > >> > > >> https://github.com/aide/aide/ > > >> > > >> It is a GPL v2 tool for monitoring file system changes. > > >> > > >> There was no (mature?) Windows open source solution until AIDE was built > > >> and tested for > > >> Cygwin. This fills a long standing gap in needs. > > >> > > >> Closed source alternative - Trip Wire. > > >> > > >> It is packaged and shipped with most Linux distributions - I am most > > >> familiar with the > > >> RHEL packaging. > > >> > > >> I have built and tested the most recent stable and development versions. > > >> > > >> I will track the development versions for test package releases. > > >> > > >> Category Security. > > >> > > >> Thoughts? > > > > > > There has been no response. It has been in test locally for 2 months now. > > > > > > May I push the cygport to git and provide a test release? > > > > > > Upstream has expressed willingness to review/track patches, if needed. > > > > > > > Hi, > > > > Thanks for offering to package and maintain this package, and apologies > > for the delay in responding. > > > > Notwithstanding [1] (which needs updating), I look for 2 things in an ITP: > > > > - a statement that the software uses an acceptable open-source license > > GPL v2, mentioned in the above original email. > > > - the cygport file (as an attachemnt or link) so it can be reviewed and > > tested > > The attached (with required patch) has been in testing on multiple windows > servers since > late July. They can also be reviewed on github [2]. > > > > > If you're still interested in progressing this, please provide the > > cygport file for discussion. > > > > [1] https://cygwin.com/packaging-contributors-guide.html#submitting > > Interested, very interested. I am on the aide developers list to track > updates, bugs, and > patches. > > v/r, > > Jason Pyeron > > 2: https://github.com/pdinc-oss/aide/tree/cygport Anyone interested in reviewing? Can I put this out there as a test package - there are many not on this mailing list that would test but would not build it. -Jason
Re: [ITA] lua-crypto-0.3.2p4
On Tue, 9 Nov 2021 19:17:29 +0100, Marco Atzeri via Cygwin-apps > On 07.11.2021 13:07, Lemures Lemniscati via Cygwin-apps wrote: > > On Sun, 07 Nov 2021 20:46:25 +0900, Lemures Lemniscati > >> On Sat, 23 Oct 2021 19:44:25 +0200, Achim Gratz > >>> > > > > > Hi, > > > > ITA for lua-crypto-0.3.2p4, just because of necessity for rebuilding it > > with libssl1.0. > > > > Regards, > > > > Lem > > > changed to you Thank you, Marco. Lem
Re: [PATCH] Cygwin: pipe: Handle WAIT_CANCELED when waiting read_mtx.
On Nov 10 17:23, Takashi Yano wrote:
> - Add missing handling for WAIT_CANCELED in cygwait() for read_mtx
> in raw_read().
> ---
> winsup/cygwin/fhandler_pipe.cc | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
> index bc06d157c..13731437e 100644
> --- a/winsup/cygwin/fhandler_pipe.cc
> +++ b/winsup/cygwin/fhandler_pipe.cc
> @@ -302,10 +302,18 @@ fhandler_pipe::raw_read (void *ptr, size_t& len)
>set_errno (EAGAIN);
>len = (size_t) -1;
>return;
> -default:
> +case WAIT_SIGNALED:
>set_errno (EINTR);
>len = (size_t) -1;
>return;
> +case WAIT_CANCELED:
> + pthread::static_cancel_self ();
> + /* NOTREACHED */
> +default:
> + /* Should not reach here. */
> + __seterrno ();
> + len = (size_t) -1;
> + return;
> }
>while (nbytes < len)
> {
> --
> 2.33.0
ACK. Please push.
Thanks,
Corinna
Could rm remove files and folders with colon in their name?
Dear All,
I've searched if this topic has come up before but could not find it.
Could 'rm' support removing files and folders that have a colon ':' in
their name? I.e. I would like that 'rm -fr' would remove a full directory
tree, including such folders. Currently it will correctly remove anything
inside such folders, but not the folder itself.
As an example, for the following structure:
C:/root/folder/C:/inside/file.txt
When using 'rm -fr root', afterwards I have:
C:/root/folder/C:
To remove everything, I can use 'find root -depth -exec rmdir \{\} \;'
I understand that files and folders with colon in their name are illegal
on Windows and not supported very well. But a number of tools manage to
create (and also remove) such files. I've found that even the native
'del' can support this when using the UNC name (see for example
https://serverfault.com/a/96833). It would be great if Cygwin could
also feature this support.
All the best,
Mario
PS: These folders are created when I use the Cygwin-based build system
for ICU (see
https://unicode-org.github.io/icu/userguide/icu4c/build.html#how-to-build-and-install-on-windows-with-cygwin)
For me this is in a combination with native Perl for Windows (ActivePerl,
in my case), and using absolute build paths. After using ICU's build
system, I can not remove the build tree anymore. It may be possible to
solve this on the ICU side too. But their automake-and-Perl-based path
mangling is not easily modified, and I've failed to isolate the root
cause of the illegal paths.
--
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
[PATCH] Cygwin: pipe: Handle WAIT_CANCELED when waiting read_mtx.
- Add missing handling for WAIT_CANCELED in cygwait() for read_mtx
in raw_read().
---
winsup/cygwin/fhandler_pipe.cc | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
index bc06d157c..13731437e 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -302,10 +302,18 @@ fhandler_pipe::raw_read (void *ptr, size_t& len)
set_errno (EAGAIN);
len = (size_t) -1;
return;
-default:
+case WAIT_SIGNALED:
set_errno (EINTR);
len = (size_t) -1;
return;
+case WAIT_CANCELED:
+ pthread::static_cancel_self ();
+ /* NOTREACHED */
+default:
+ /* Should not reach here. */
+ __seterrno ();
+ len = (size_t) -1;
+ return;
}
while (nbytes < len)
{
--
2.33.0
