On Tue, May 13, 2025 at 9:07 PM Brian Inglis via Cygwin <cygwin@cygwin.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.couderc2...@gmail.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
