DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 54ND3FUB1029883
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 164B93857359
MIME-Version: 1.0
References: <CA+1jF5oPR8s20fEpadcdpE8TA+H_0P-inL8sSax7zz3QAcxLWg AT mail DOT gmail DOT com>
 <6ec5c987-b2ff-421d-b8f4-8b1ee7dca29c AT SystematicSW DOT ab DOT ca>
 <CA+1jF5orHBdQ3fQOY7FVGYwQYpVWS=TFnXbtcwxHh512fr4hQw AT mail DOT gmail DOT com>
 <8c0312e1-a37d-433a-bea2-6eec96eda5af AT SystematicSW DOT ab DOT ca>
 <CA+1jF5pfP1543kQz4X=2xVHuoH-Yfh1n1ntXkabSc++B_DU_Uw AT mail DOT gmail DOT com>
 <b5f51dbe-5715-406f-b132-d59cc665fc74 AT SystematicSW DOT ab DOT ca>
In-Reply-To: <b5f51dbe-5715-406f-b132-d59cc665fc74@SystematicSW.ab.ca>
Date: Fri, 23 May 2025 15:02:09 +0200
Message-ID: <CA+1jF5qP6tUTB0DoH+LtAizjEdHxOVCFuWcf5gTX9pA50iro4w@mail.gmail.com>
Subject: Re: Using Cygwin installation on network share in CI fails
To: cygwin AT cygwin DOT com
From: =?utf-8?q?Aur=C3=A9lien_Couderc_via_Cygwin?= <cygwin AT cygwin DOT com>
Reply-To: =?UTF-8?Q?Aur=C3=A9lien_Couderc?= <aurelien DOT couderc2002 AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On Tue, May 13, 2025 at 9:07 PM Brian Inglis via Cygwin
<cygwin AT cygwin DOT com> wrote:
>
> On 2025-05-13 10:32, Aurélien Couderc via Cygwin wrote:
> > On Tue, May 13, 2025 at 5:41 PM Brian Inglis via Cygwin wrote:
> >> On 2025-05-13 02:33, Aurélien Couderc via Cygwin wrote:
> >>> On Mon, May 12, 2025 at 7:43 PM Brian Inglis via Cygwin wrote:
> >>>> On 2025-05-12 10:34, Aurélien Couderc via Cygwin wrote:
> >>>>> Using Cygwin install on network share in CI fails.
> >>>>> This seems to be a recent regression, as this was working a year before.
> >>
> >> If you have not run it in a year, it is possibly many things have changed in
> >> your environment.
> >
> > The CI runs for *every* commit, with hundreds of commits a day.
> >
> > My... crime... was to update Cygwin to Cygwin 3.6.1. After that,
> > Cygwin no longer works on WIndows network shares.
> >
> >>>>> Now on Windows 10 with Cygwin 3.6.1 it fails with error 127.
> >>>> That can mean a missing DLL function entry.
> >>
> >>> No, I do not think so, as Cygwin works fine if I install it on NTFS.
> >>
> >> So you are not installing it on NTFS?
> >> What kind of share are you installing it on?
> >
> > Windows 10 Enterprise (NT-10.0-19045), we use net use N: ... to mount
> > the standard Windows network share. AFAIK this is Server Message Block
> > 3.1.
>
> SMB is a network protocol not a storage file system.
> What is the underlying file system?

NTFS

All systems used to demonstrate the issue are a fresh install, no
baggage from years of usage etc

>
> >> Are you installing it using the *latest* download of Cygwin Setup from
> >>
> >>          https://cygwin/com/setup_x86_64.exe
> >
> > Yes, indeed, we did.
> >
> >>
> >> Do the installed files have all their read and exec bits set - this was an issue
> >> with a recent older release of Cygwin Setup where some files did not.
> >
> > Yes, all DLL files have, per icacls, at least RX (read, execute) set.
> >
> >>> WIndows DLLS should be fine, and the system is up to date with patches
> >>> and has a support contract.
> >>
> >> Should be is not definite!
> >> Patches have been known to cause issues!
> >> Does the support contract cover supporting the execution of Cygwin and utilities?
> >
> > I can ask Microsoft support, but seriously for Microsoft "Cygwin" is a
> > 3rd-party product.
> I assume you have an IT department which manages Enterprise builds and features?
> It can be a good idea to get them involved in Cygwin installs and QC checks that
> Cygwin still works after any of their updates.
> Remember that Cygwin runs under Windows, and Enterprise builds may drop features
> or enable policies or processes that intercept calls Cygwin's API may rely on.
>
> >>> But Cygwin fails if I install it on a Windows network share. Same
> >>> installation procedure (.\setup-x86_64.exe -q --no-write-registry
> >>> --no-admin --root %cd%
> >>> --no-desktop --site "https://mirrors.kernel.org/sourceware/cygwin"),
> >>> just different drive (N: instead of C:)
> >>
> >> A verbal description of a common failure is inadequate.
> >> We are not mind readers and have no idea how your CI environment is set up.
> >> Everything works fine in our CI environment, so your environment is defective,
> >> and we have no information allowing us to do more than speculate and suggest
> >> what may be an issue.
> >>
> >> It appears possible it is an issue with how the share you are using as a network
> >> drive is now set up.
> >> It may have been changed recently due to some process or policy change by your
> >> IT department.
> >> Please ask them what they have done recently that might affect the share you
> >> have been using successfully since 2016.
> >>
> >> Also please note that recent Windows changes have started blocking Cygwin
> >> programs with the same names as programs provided by MS (as outdated and
> >> insecure versions) like bash, curl, ssh*, tar, etc. possibly under the Windows
> >> security heading of Tamper Protection?
> >
> > I turned off WIndows Defender, for testing purposes, and the result is the same.
> >
> >> You have failed to respond to requests for actual information about or from the
> >> failing environment.
> >> We need to see actual output from commands of the file system properties and
> >> directory contents and permissions.
> >
> > There *IS* no output. Everything which depends on cygwin1.dll just
> > fails without output.
>
> That points to BLODA - poorly written software intercepting functions calls:
>
>         https://cygwin.com/faq/faq.html#faq.using.bloda

How should that happen? I have tested this with a fresh install of
Windows, and even turned Defender OFF. No antivirus running, no
debugger, no software to intercept system calls. Just Cygwin stopped
working in Cygwin 3.6 if it is installed on SMB (hosted on NTFS on the
server side), which worked since years with older versions of Cygwin

>
> Try installing Cygwin on a local drive and check it works, then use that to
> check your setup.
>
> >> Maybe follow the problem reporting guidelines to run cygcheck -hrsv in the CI
> >> and include the output as a plain text attachment to your post.
> >
> > I need to anonymise that, or IT will want my reprimation.
> >
> > But the steps I posted fail on ANY Windows 10 and Windows 11 machine I
> > have tested so far, Windows Home, Enterprise and Pro.
> > All you need are the steps I posted, the KEY being doing an
> > installation on Windows Server Message Block filesystem. That is all.
> SMB is a network protocol not a storage file system.
> What is the underlying file system?
> No one else is reporting any such problems, so it is your environment, with your
> network share, that is now having issues.

I think no one reported it because it is a new problem, and Cygwin is
not updated every week

Aurélien
-- 
Aurélien Couderc <aurelien DOT couderc2002 AT gmail DOT com>
Big Data/Data mining expert, chess enthusiast

-- 
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