[PATCH] fchmodat/fstatat: fix regression with empty `pathname`
In 4b8222983f (Cygwin: fix errno values set by readlinkat, 2023-04-18)
the code of `readlinkat()` was adjusted to align the `errno` with Linux'
behavior.
To accommodate for that, the `gen_full_path_at()` function was modified,
and the caller was adjusted to expect either `ENOENT` or `ENOTDIR` in
the case of an empty `pathname`, not just `ENOENT`.
However, `readlinkat()` is not the only caller of that helper function.
And while most other callers simply propagate the `errno` produced by
`gen_full_path_at()`, two other callers also want to special-case empty
`pathnames` much like `readlinkat()`: `fchmodat()` and `fstatat()`.
Therefore, these two callers need to be changed to expect `ENOTDIR` in
case of an empty `pathname`, too.
Signed-off-by: Johannes Schindelin
---
Published-As:
https://github.com/dscho/msys2-runtime/releases/tag/fix-tar-xf-with-symlinks-cygwin-v1
Fetch-It-Via: git fetch https://github.com/dscho/msys2-runtime
fix-tar-xf-with-symlinks-cygwin-v1
I noticed this issue when one of my workflows failed consistently
while trying to untar an archive containing a symbolic link and
claiming this:
Cannot change mode to rwxr-xr-x: Not a directory
With this here fix, things start working as expected again.
winsup/cygwin/syscalls.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 73343ecc1f..c1889aec91 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -4580,7 +4580,7 @@ fchownat (int dirfd, const char *pathname, uid_t uid,
gid_t gid, int flags)
int res = gen_full_path_at (path, dirfd, pathname);
if (res)
{
- if (!(errno == ENOENT && (flags & AT_EMPTY_PATH)))
+ if (!((errno == ENOENT || errno == ENOTDIR) && (flags &
AT_EMPTY_PATH)))
__leave;
/* pathname is an empty string. Operate on dirfd. */
if (dirfd == AT_FDCWD)
@@ -4625,7 +4625,7 @@ fstatat (int dirfd, const char *__restrict pathname,
struct stat *__restrict st,
int res = gen_full_path_at (path, dirfd, pathname);
if (res)
{
- if (!(errno == ENOENT && (flags & AT_EMPTY_PATH)))
+ if (!((errno == ENOENT || errno == ENOTDIR) && (flags &
AT_EMPTY_PATH)))
__leave;
/* pathname is an empty string. Operate on dirfd. */
if (dirfd == AT_FDCWD)
base-commit: 4c7d0dfec5793cbf5cf3930b91f930479126d8ce
--
2.41.0.windows.1
Re: installer crashed on Windows 11; ERROR_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION}
On 23/06/2023 20:26, Rupin Dhanoa via Cygwin wrote:
Hi Guys,
setup-x86_64.exe crashing from me on Windows 11 (Version 10.0.22621 Build
22621) on dell laptop (12th Gen Intel i7-12800H, 2400 Mhz).
Memory dump analysis in Windows debugger shows:
Thanks for this report.
You didn't mention what version of setup you are using, and when it
fails (I assume the latest, and on startup).
This looks like (another) failure after UPX decompression.
At the moment, the only solution I can suggest for you to try is to
download UPX [2] and run 'upx -d' on the setup executable to uncompress it.
[1] https://cygwin.com/pipermail/cygwin/2022-August/252131.html
[2] https://upx.github.io/
CONTEXT: (.ecxr)
rax=0224 rbx=007b80d0 rcx=00905b48
rdx=0352 rsi=00401000 rdi=008f0008
rip=00505c27 rsp=00b0fed8 rbp=
r8=00b0d4e0 r9=00b0d4b8 r10=007f38c0
r11=008a0712 r12= r13=
r14= r15=
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010200
setup_x86_64__4_+0x105c27:
`00505c27 d6 ???
Resetting default scope
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00505c27 (setup_x86_64__4_+0x00105c27)
ExceptionCode: c01d (Illegal instruction)
ExceptionFlags:
NumberParameters: 0
PROCESS_NAME: setup-x86_64 (4).exe
ERROR_CODE: (NTSTATUS) 0xc01d - {EXCEPTION} Illegal Instruction An
attempt was made to execute an illegal instruction.
EXCEPTION_CODE_STR: c01d
STACK_TEXT:
`00b0fed8 `008f4c4d : ` `004f24da
`006e13fc `00b0c040 : setup_x86_64__4_+0x105c27
`00b0fee0 ` : `004f24da `006e13fc
`00b0c040 `00401000 : setup_x86_64__4_!BZ2_bzerror+0x365f8d
FAILED_INSTRUCTION_ADDRESS:
setup_x86_64__4_+105c27
`00505c27 d6 ???
--
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 confusing error from someone else's Cygwin setup
The line endings were the issue, thanks. They were that way because I
didn't realize I should force those files in git to have eol=lf in a
.gitattributes file. This is now all fixed.
On Mon, Jun 26, 2023 at 7:08 PM Mike Gran wrote:
> > On Monday, June 26, 2023 at 04:36:30 PM PDT, David Karr via Cygwin <
> cygwin@cygwin.com> wrote:
>
> > m seeing a problem with someone else's Cygwin setup, sort of similar to a
> > problem I asked about a couple of weeks ago, in that it's a problem with
> > the same user, but seemingly a completely different problem.
>
> ...
>
> > He was getting a weird error on line 3, just saying this:
> > -
> > ...: line 3: syntax error near unexpected token `$'{\r''
> > ...: line 3: `main() {
> > ---
>
> If you run bash with the "-o igncr" option, it will ignore extraneous
> carriage return characters.
>
> But the characters are there in the first place because your
> script has been converted into using Windows line endings:
> carriage return + linefeed.
>
> You didn't say how the script was transferred, but lots
> of programs could add returns when you transfer something
> to windows: git or ftp just to name a few.
>
> You both could try running "bash --version". The first line should
> say something like
> "GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)"
>
> Note the "pc-cygwin" at the end.
>
> HTH,
> Mike Gran
>
--
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: dtable: Delete old kludge code for /dev/tty.
This old kludge code assigns fhandler_console for /dev/tty even
if the CTTY is not a console when stat() has been called. Due to
this, the problem reported in
https://cygwin.com/pipermail/cygwin/2023-June/253888.html
occurs after the commit 3721a756b0d8 ("Cygwin: console: Make the
console accessible from other terminals.").
This patch fixes the issue by dropping the old kludge code.
Reported-by: Bruce Jerrick
Signed-off-by: Takashi Yano
---
winsup/cygwin/dtable.cc | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/winsup/cygwin/dtable.cc b/winsup/cygwin/dtable.cc
index 18e0f3097..9427e238e 100644
--- a/winsup/cygwin/dtable.cc
+++ b/winsup/cygwin/dtable.cc
@@ -598,12 +598,7 @@ fh_alloc (path_conv& pc)
fh = cnew (fhandler_mqueue);
break;
case FH_TTY:
- if (!pc.isopen ())
- {
- fhraw = cnew_no_ctor (fhandler_console, -1);
- debug_printf ("not called from open for /dev/tty");
- }
- else if (!CTTY_IS_VALID (myself->ctty) && last_tty_dev
+ if (!CTTY_IS_VALID (myself->ctty) && last_tty_dev
&& !myself->set_ctty (fh_last_tty_dev, 0))
debug_printf ("no /dev/tty assigned");
else if (CTTY_IS_VALID (myself->ctty))
--
2.39.0
Re: Slow startup time on AD joined PCs
I tried the second workaround and it solved the problem for me. I'll update
the GitHub issue with this and suggest that others try the same thing as
well. Thanks!
În lun., 26 iun. 2023 la 17:12, Brian Inglis a scris:
> On 2023-06-26 00:15, Cristi Anichitei via Cygwin wrote:
> > This has been initially reported as a Git for Windows issue:
> > https://github.com/git-for-windows/git/issues/4459
> >
> > But it has been tracked down to originate in the Cygwin project (see
> >
> https://github.com/git-for-windows/git/issues/4459#issuecomment-1580526636
> > and maybe
> >
> https://github.com/git-for-windows/git/issues/4459#issuecomment-1602566700
> ).
> >
> > Using 3.4.6.1 (from
> >
> http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/cygwin/cygwin-3.4.6-1-src.tar.xz
> ),
> > running any program from /usr/bin takes at least 20 seconds, for example
> >
> > $ .\ldd.exe --version
> > ldd (cygwin) 3.4.6
> > Print shared library dependencies
> > Copyright (C) 2009 - 2023 Chris Faylor
> > This is free software; see the source for copying conditions. There is
> NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> > $ Measure-Command { .\ldd.exe --help }
> > Days : 0
> > Hours : 0
> > Minutes : 0
> > Seconds : 22
> > Milliseconds : 552
> > Ticks : 225529747
> > TotalDays : 0.000261029799768519
> > TotalHours: 0.0062647151944
> > TotalMinutes : 0.37588291167
> > TotalSeconds : 22.5529747
> > TotalMilliseconds : 22552.9747
> >
> > I have also tried this with 3.4.7 - same issue.
> >
> > Using 3.1.7 there is no slow down. I haven't tried any versions between
> > 3.1.7 and 3.4.7 yet, but I can do that.
> >
> > I'm running Windows 10 21H2 (19044.3086).
>
> https://cygwin.com/faq.html#faq.using.startup-slow
>
> Probably slow AD server or network connection, or long group membership
> lists,
> that can be ameliorated by running cygserver service at system startup, so
> only
> the first Cygwin process takes SAM/AD access hits, which are cached
> thereafter,
> and shared with all Cygwin processes on the system.
> Otherwise the first Cygwin process in each Cygwin process tree takes the
> hits,
> so if you are not running under Cygwin mintty terminal and/or Cygwin
> shell,
> every Cygwin process run from a Windows shell has to load all the SAM/AD
> info
> required to run the Cygwin process.
>
> --
> 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
[ITA] ruby-atk 4.1.7
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-atk Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5383991799 ruby-atk.cygport.diff Description: Binary data
