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?
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
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.
P.S: I hereby propose a cygcheck -A (anonymise) option, which should
replace hostname, IP addresses and other sensitive data with one way
hashes like MD4 or MD5
It is quite easy to script converting environment values back into variable
names for any level of anonymity you care to enforce.
Do not make it more difficult than necessary for us volunteers to read the
information you provide to help you diagnose issues.
--
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 à retrancher 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
