Re: objects created in a dir w/cygwin mangled perms; inherit no-access
Greetings, L A Walsh! > On 2021/07/07 11:43, Andrey Repin wrote: What is "progd" ? Did you mount some directory into Cygwin tree? >> >>> Sorta, actually the cygtree mounted at 'C:\'. >> >> Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally >> opted out of it. > --- > If you have something unexpected happening on your own > computer, and you choose not to find the cause, you really don't > know if it was a virus, malware or some other problem. I've found the cause, which does not change the fact the documented behavior was undesirable. This is, after all, whyinstalling Cygwin in a system root is discouraged. > I've had my directory tree mounted the way it is since > Windows XP, and have tried to understand issues about computers > that many term "magick" (or black magick). Being a computer > scientist, I've always tried to understand what was going on. > I don't always find out quickly, but I often return to problems > that I haven't solved years later to sometimes find the cause, or > sometimes find the problems have gone away. > Considering my life has been about computers, opting out > has really not been an option for me. "Doctor, when I poke my eye with a knife, it pains me!" >>> Certainly, having it create no-access dirs >>> for the user isn't desirable. I'm betting that they'd >>> be denied locally as well if my local user didn't >>> have admin override rights. >> >> It may be something in the parent directory. > --- > Nope... can't be, windows doesn't work that way. > A directory can affect its contents, but permissions that are > inherited can't skip a generation. > or fstab mount options. > --- > I pretty much use the default: > > # /etc/fstab > # > #This file is read once by the first process in a Cygwin > #process tree. To pick up changes, restart all Cygwin > #processes. For a description > #see https://cygwin.com/cygwin-ug-net/using.html#mount-table > # This is default anyway: > none / cygdrive binary,posix=0,user 0 0 > This, basically, tells Cygwin to override Windows permissions manager. Creating all sort of permission issues for unsuspecting Windows programs. Saner approach would be to leave Windows permissions to Windows. none / cygdrive noacl,binary,nouser,posix=0 0 0 C:/Users /home bind noacl,binary,exec,posix=0 0 0 none /tmp usertemp binary,nouser,posix=1 0 0 But then again, consider you have two conflicting permission schemes over directories on the system drive. >> Needs a more thorough investigation. But I think it would easily be avoided >> by a saner directory layout. > --- > What is more sane, ignoring a problem that was opted out > of for 20 years, or understand what causes problems. That's baseless assumption. The problem was thoroughly investigated and the final decision was that the lowest number of workarounds is preferable. > I can't speak for Windows 10, but through Windows 7, > especially in the X64 world, it makes little to no sense to > cut your cygwin tools off from being able to access and work > on your windows installation. Eh? I have Cygwin in %PATH% and use its tools primarily, even though I have Git for Windows for example. Which I only use for VS Code. Exception is curl and tidy, both of which I have native builds. > If you have ever boot to a rescue system running from > your hard drive -- you have the choice of using all your cygwin > tools to recover your system, or to just use Windows tools. I have my own rescue system. I'm a support engineer after all. These are tools of my trade. And for the record, TakeCommand is more useful for rescue tool than Cygwin. I have both. > If you have 30+ years of unix/linux/posix experience > with linux/posix tools, does it make any sense to throw that > away when trying to recover your system? When system is not Linux/UNIX? Absolutely. Use right tool for the job. I only have 12 or so years of *NIX experience, and I would never ditch a chance of using bash script to do the work for me, but if I have a choice of native tool that's almost equivalent in performance, I'd use that. > X64 Cygwin tools work natively when installed at root. They work equally well when installed in C:\Programs\Cygwin64. JFYI. > Many of the Windows tools are still x32 which won't run on a rescue system. That's why I opted for 64-bit tools where possible. In my experience, they work faster on 64-bit system, than 32-bit tools, even if built from same source. > Linux xfs has 2 acls on directories -- one for the directory > and one that can be the default for contents to inherit. It's > not identical to windows, but it is similar and if you > understand one, the other isn't that different. Cygwin > has placed the most emphasis on POSIX compatibility vs. > Windows compatibility. In some places it could have been > more Windows compatible and still achieved POSIX compat. I'
Re: Setup shows errors from gnuplot-base.dash and python38-devel.sh
Greetings, Doug Henderson! >> >>> When I do that in an elevated shell: >> >>> >> >>> $ cd /etc/postinstall/ >> >>> >> >>> $ cat gnuplot-base.dash >> >>> /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot >> >>> /usr/bin/gnuplot-base.exe 10 >> >>> >> >>> $ . gnuplot-base.dash >> >>> failed to read link /usr/bin/gnuplot: No such file or directory >> >>> failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such >> >>> file or directory >> >> >> >> Something seems to be confusing 'alternatives'. Can you show a listing of >> >> /etc/alternatives? >> > >> > $ cd /etc/alternatives/ >> > >> > $ ls -l >> > total 2.0K >> > lrwxrwxrwx 1 Admin None 35 Oct 3 2017 automake-doc -> >> > /usr/share/info/automake1.9.info.gz >> > lrwxrwxrwx 1 Admin None 19 Jun 16 17:48 lua -> /usr/bin/lua5.3.exe* >> > lrwxrwxrwx 1 Admin None 31 Jun 16 17:48 lua.1.gz -> >> > /usr/share/man/man1/lua5.3.1.gz >> > lrwxrwxrwx 1 Admin None 20 Jun 16 17:48 luac -> /usr/bin/luac5.3.exe* >> > lrwxrwxrwx 1 Admin None 32 Jun 16 17:48 luac.1.gz -> >> > /usr/share/man/man1/luac5.3.1.gz >> > lrwxrwxrwx 1 Admin None 15 Jun 5 08:46 pip3 -> /usr/bin/pip3.8* >> > lrwxrwxrwx 1 Admin None 22 Jun 16 07:34 python -> /usr/bin/python3.8.exe* >> > -rw-r--r-- 1 Admin None 163 Apr 4 2013 README >> >> This shows that alternatives worked in June. Have you changed anything since >> then that might be related to symlinks (e.g., the CYGWIN environment >> variable)? >> >> Here are a few other things you could try: >> >> 1. Attach cygcheck output as requested in https://cygwin.com/problems.html >> >> 2. Add --verbose to the alternatives call. >> >> 3. Run the alternatives call under strace and look for errors involving >> symlinks. Or post the output somewhere so that we can look at it. > Now using setup-x86_64.exe version 2.909 (64 bit) > Postinstall script errors: > Package: _/Unknown package > gnuplot-base.dash exit code 2 > python38-devel.sh exit code 2 > Here's what I did in an elevated shell. > $ cd /etc/alternatives > $ cat /etc/postinstall/gnuplot-base.dash > /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot > /usr/bin/gnuplot-base.exe 10 > $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot > /usr/bin/gnuplot-base.exe 10 > reading /var/lib/alternatives/gnuplot > failed to read link /usr/bin/gnuplot: No such file or directory > failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such > file or directory > $ echo $CYGWIN > winsymlinks:nativestrict > *** changed system environment > $ echo $CYGWIN > winsymlinks:native > $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot > /usr/bin/gnuplot-base.exe 10 > reading /var/lib/alternatives/gnuplot > *** Success > Alternatives does not work correctly when CYGWIN=nativestrict. Perhaps > it is trying to create a link before the link target exists. Unlike > Linux, Windows does not allow creating symbolic links to non-existent > targets. > The /etc/postinstall/python38-devel.sh also works now. > Also after changing env back to CYGWIN=winsymlinks:nativestrict the > erroring postinstall scripts continue to work. This supports my > suspicion that /usr/sbin/alternatives is trying to create a symbolic > link to a target before it creates the target when it is performing > the first install for an alternative. On subsequent runs, the target > already exists. > I have unattached the output from cygcheck, as I do not believe it > will help now. > Am I the only person that uses "CYGWIN=winsymlinks:nativestrict" ??? $ echo "$CYGWIN" wincmdln winsymlinks:nativestrict glob:ignorecase > Sorry for all the bother. My aging brain forgot how I made > alternatives work for Lua last month. I've stumbled upon the same problem earlier. alternatives tries to create a link pointing to a nonexistent file. Which is valid in Linux, but impossible in Windows. IMO, this is a logical fallacy and should not be attempted, making it an upstream bug. -- With best regards, Andrey Repin Friday, July 16, 2021 6:56:55 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: Updated: setup (2.909)
I adjusted the column widths because there seems to be a lot of unused space, which makes for a very wide window. But when I restart the Cygwin setup application, the columns return to their default widths. Could a feature be added to save the column widths from run to run? -- Jim Reisert AD1C, , https://www.ad1c.us -- 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: Setup shows errors from gnuplot-base.dash and python38-devel.sh
Doug Henderson via Cygwin writes: > Alternatives does not work correctly when CYGWIN=nativestrict. Perhaps > it is trying to create a link before the link target exists. Unlike > Linux, Windows does not allow creating symbolic links to non-existent > targets. Which is one reason why Windows symlinks are not POSIX symlinks. The real reason is that you need to need to tell Windows whether you're pointing the symlink at a directory or a file when the target does not yet exist. > Am I the only person that uses "CYGWIN=winsymlinks:nativestrict" ??? Well, you should certainly pay more attention to where, when and how it breaks. It papers over one of the differences between the POSIX and Windows world, but creates another gap elsewhere. This is exactly why I have backed out the commit that uses the CYGWIN environment variable in setup.exe. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: Setup shows errors from gnuplot-base.dash and python38-devel.sh
"On Thu, 15 Jul 2021 at 05:59, Ken Brown via Cygwin wrote: > > On 7/14/2021 9:20 PM, Doug Henderson via Cygwin wrote: > > On Wed, 14 Jul 2021 at 16:33, Ken Brown via Cygwin > > wrote: > >> > >> On 7/14/2021 5:08 PM, Doug Henderson via Cygwin wrote: > >>> On Wed, 14 Jul 2021 at 13:03, Achim Gratz wrote: > > Doug Henderson via Cygwin writes: > > The first error message occurred when I installed all pending packages > > this morning. I hoped to heal the problem by reinstalling the > > installed gnuplot packages. Now I get both the messages. > > If you look in /var7Log/setup.log.full you should be able to see what > error messages, if any, were recorded. > > The gnuplot related script should just set up the current alternative > for "gnuplot" to use, but something on your system seems to prevent > that from happening. You can also run the script in sh (you must tell > the shell to source it) and should get the same error (most likely). > >>> > >>> When I do that in an elevated shell: > >>> > >>> $ cd /etc/postinstall/ > >>> > >>> $ cat gnuplot-base.dash > >>> /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot > >>> /usr/bin/gnuplot-base.exe 10 > >>> > >>> $ . gnuplot-base.dash > >>> failed to read link /usr/bin/gnuplot: No such file or directory > >>> failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such > >>> file or directory > >> > >> Something seems to be confusing 'alternatives'. Can you show a listing of > >> /etc/alternatives? > > > > $ cd /etc/alternatives/ > > > > $ ls -l > > total 2.0K > > lrwxrwxrwx 1 Admin None 35 Oct 3 2017 automake-doc -> > > /usr/share/info/automake1.9.info.gz > > lrwxrwxrwx 1 Admin None 19 Jun 16 17:48 lua -> /usr/bin/lua5.3.exe* > > lrwxrwxrwx 1 Admin None 31 Jun 16 17:48 lua.1.gz -> > > /usr/share/man/man1/lua5.3.1.gz > > lrwxrwxrwx 1 Admin None 20 Jun 16 17:48 luac -> /usr/bin/luac5.3.exe* > > lrwxrwxrwx 1 Admin None 32 Jun 16 17:48 luac.1.gz -> > > /usr/share/man/man1/luac5.3.1.gz > > lrwxrwxrwx 1 Admin None 15 Jun 5 08:46 pip3 -> /usr/bin/pip3.8* > > lrwxrwxrwx 1 Admin None 22 Jun 16 07:34 python -> /usr/bin/python3.8.exe* > > -rw-r--r-- 1 Admin None 163 Apr 4 2013 README > > This shows that alternatives worked in June. Have you changed anything since > then that might be related to symlinks (e.g., the CYGWIN environment > variable)? > > Here are a few other things you could try: > > 1. Attach cygcheck output as requested in https://cygwin.com/problems.html > > 2. Add --verbose to the alternatives call. > > 3. Run the alternatives call under strace and look for errors involving > symlinks. Or post the output somewhere so that we can look at it. Now using setup-x86_64.exe version 2.909 (64 bit) Postinstall script errors: Package: _/Unknown package gnuplot-base.dash exit code 2 python38-devel.sh exit code 2 Here's what I did in an elevated shell. $ cd /etc/alternatives $ cat /etc/postinstall/gnuplot-base.dash /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 reading /var/lib/alternatives/gnuplot failed to read link /usr/bin/gnuplot: No such file or directory failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such file or directory $ echo $CYGWIN winsymlinks:nativestrict *** changed system environment $ echo $CYGWIN winsymlinks:native $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 reading /var/lib/alternatives/gnuplot *** Success Alternatives does not work correctly when CYGWIN=nativestrict. Perhaps it is trying to create a link before the link target exists. Unlike Linux, Windows does not allow creating symbolic links to non-existent targets. The /etc/postinstall/python38-devel.sh also works now. Also after changing env back to CYGWIN=winsymlinks:nativestrict the erroring postinstall scripts continue to work. This supports my suspicion that /usr/sbin/alternatives is trying to create a symbolic link to a target before it creates the target when it is performing the first install for an alternative. On subsequent runs, the target already exists. I have unattached the output from cygcheck, as I do not believe it will help now. Am I the only person that uses "CYGWIN=winsymlinks:nativestrict" ??? Sorry for all the bother. My aging brain forgot how I made alternatives work for Lua last month. HTH Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com -- 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: setup-x86_64.exe crashes randomly on user interaction, too often to use
On 14/07/2021 21:06, Philip Goetz via Cygwin wrote: On Wed, Jul 14, 2021 at 2:57 PM Philip Goetz wrote: On Wed, Jul 14, 2021 at 9:10 AM Jon Turney wrote: On 13/07/2021 20:30, Philip Goetz via Cygwin wrote: ... I change display mode from Pending to Category, and start clicking through the category tree selecting packages. But every time I click on something in the cygwin setup window, or scroll the window, there's maybe 1 chance in 10 that setup-x86_64.exe will terminate. ... I'd like to try using an older Cygwin installer, but I didn't find links to older versions on cygwin.com. You can find older version of setup at https://cygwin.com/setup/ Thank you! I tried setup-2.905.x86_64.exe and setup-2.907.x86_64.exe, and neither gave me any problems! I spoke too soon. I just ran setup-2.907.x86_64.exe again, to install some more programs, and it did the same thing. But I spent a long time in 2.905 without it crashing. Thanks to the reproduction steps, I was able to (finally) develop some useful information about this crash, and that is consistent with where I think the problem was introduced. I've built setup 2.909 with a putative fix for this. Perhaps you could try that and see if it improves things for you? Thanks. -- 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: setup (2.909)
A new version of Setup (2.909) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Changes compared to 2.908: - Fix a sporadic crash which could occur while using the package chooser GUI (a regression since 2.906) Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248893.html - Various cosmetic fixes For instructions on obtaining and building the source code for setup, see https://sourceware.org/cygwin-apps/setup.html Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. -- 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: Setup shows errors from gnuplot-base.dash and python38-devel.sh
On 7/14/2021 9:20 PM, Doug Henderson via Cygwin wrote: On Wed, 14 Jul 2021 at 16:33, Ken Brown via Cygwin wrote: On 7/14/2021 5:08 PM, Doug Henderson via Cygwin wrote: On Wed, 14 Jul 2021 at 13:03, Achim Gratz wrote: Doug Henderson via Cygwin writes: The first error message occurred when I installed all pending packages this morning. I hoped to heal the problem by reinstalling the installed gnuplot packages. Now I get both the messages. If you look in /var7Log/setup.log.full you should be able to see what error messages, if any, were recorded. The gnuplot related script should just set up the current alternative for "gnuplot" to use, but something on your system seems to prevent that from happening. You can also run the script in sh (you must tell the shell to source it) and should get the same error (most likely). When I do that in an elevated shell: $ cd /etc/postinstall/ $ cat gnuplot-base.dash /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 $ . gnuplot-base.dash failed to read link /usr/bin/gnuplot: No such file or directory failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such file or directory Something seems to be confusing 'alternatives'. Can you show a listing of /etc/alternatives? $ cd /etc/alternatives/ $ ls -l total 2.0K lrwxrwxrwx 1 Admin None 35 Oct 3 2017 automake-doc -> /usr/share/info/automake1.9.info.gz lrwxrwxrwx 1 Admin None 19 Jun 16 17:48 lua -> /usr/bin/lua5.3.exe* lrwxrwxrwx 1 Admin None 31 Jun 16 17:48 lua.1.gz -> /usr/share/man/man1/lua5.3.1.gz lrwxrwxrwx 1 Admin None 20 Jun 16 17:48 luac -> /usr/bin/luac5.3.exe* lrwxrwxrwx 1 Admin None 32 Jun 16 17:48 luac.1.gz -> /usr/share/man/man1/luac5.3.1.gz lrwxrwxrwx 1 Admin None 15 Jun 5 08:46 pip3 -> /usr/bin/pip3.8* lrwxrwxrwx 1 Admin None 22 Jun 16 07:34 python -> /usr/bin/python3.8.exe* -rw-r--r-- 1 Admin None 163 Apr 4 2013 README This shows that alternatives worked in June. Have you changed anything since then that might be related to symlinks (e.g., the CYGWIN environment variable)? Here are a few other things you could try: 1. Attach cygcheck output as requested in https://cygwin.com/problems.html 2. Add --verbose to the alternatives call. 3. Run the alternatives call under strace and look for errors involving symlinks. Or post the output somewhere so that we can look at it. 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: cygpath and star character
On Jul 14 15:26, Ken Brown via Cygwin wrote: > On 7/14/2021 4:10 AM, Tomas Jura via Cygwin wrote: > > Hi > > > > I found a strange behaviour of the program cygpath program > > > > 0 >cygpath -w "./*/*" <--- IMHO wrong output > > \ > > > > 0 >cygpath -w "./*/*" | od -a <--- a detailed dump > > 000 o nul * \ o nul * nl > > 010 > > What you're seeing here is a consequence of the way Cygwin handles valid > POSIX file names that contain characters (like '*') that are not allowed in > Windows file names. See "Forbidden characters in filenames" at > > https://cygwin.com/cygwin-ug-net/using-specialnames.html > > Internally, Cygwin converts "./*/*" to the wide char string L"*\*" with '*' > replaced by 0xf02a. This then gets converted to the multibyte sequence in > your "detailed dump", which is not quite detailed enough: > > $ cygpath -w "./*/*" | od -b > 000 357 200 252 134 357 200 252 012 > 010 > > I tend to agree that this is not desirable behavior. I doubt if users of > 'cygpath -w' expect to get a result that contains transformed forbidden > characters. But maybe there's a use case for this that I'm missing. > Corinna? The purpose of cygpath is to convert paths between Cygwin and Windows, so that you can access the same file in both worlds. The '*' character is a valid character in Cygwin, but the created file will have a unicode 0xf02a in its place. If cygpath doesn't convert the path accordingly, accessing the file from Windows via the converted path would fail. > > 0 >cygpath -wp "./*/*" <-- but this works as expected > > *\* > > > > Is this bug or expected behavior ? > > It looks to me like a bug that 'cygpath -w' and 'cygpath -wp' give different > results on a path that doesn't contain a colon. Yeah, that's not quite right. Historically, the conversion of path lists is performed on multibyte paths, not on wide char paths. This has never been changed, and that results in special characters getting lost. So in fact, the behaviour in -p is wrong for those chars invalid in Windows and only valid for POSIX paths. 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: objects created in a dir w/cygwin mangled perms; inherit no-access
On 15/07/2021 08:02, L A Walsh wrote: On 2021/07/07 11:43, Andrey Repin wrote: Sorta, actually the cygtree mounted at 'C:\'. Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. If you have ever boot to a rescue system running from your hard drive -- you have the choice of using all your cygwin tools to recover your system, or to just use Windows tools. After wading through the unsolicited self-congratulation a few observations. 1. You want support from the Cygwin community for problems you're having despite having installed it in a way that is expressly discouraged. (https://cygwin.com/faq.html#faq.setup.c) Good luck with that. 2. You've not bothered to search the archives or even read the manual, specifically https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files but instead immediately assume a flaw in the code. Not very scientific ... or polite. (By the way, the permission workaround is another good reason for not installing in system root if advice from the authors of Cygwin - Corinna et al - isn't enough for you.) 3. Installing Cygwin under, say, C:\cygwin64 does not prevent you from using it for recovery. PEBCAK -- Sam Edge -- 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: objects created in a dir w/cygwin mangled perms; inherit no-access
On 2021/07/07 11:43, Andrey Repin wrote: What is "progd" ? Did you mount some directory into Cygwin tree? Sorta, actually the cygtree mounted at 'C:\'. Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. --- If you have something unexpected happening on your own computer, and you choose not to find the cause, you really don't know if it was a virus, malware or some other problem. I've had my directory tree mounted the way it is since Windows XP, and have tried to understand issues about computers that many term "magick" (or black magick). Being a computer scientist, I've always tried to understand what was going on. I don't always find out quickly, but I often return to problems that I haven't solved years later to sometimes find the cause, or sometimes find the problems have gone away. Considering my life has been about computers, opting out has really not been an option for me. Certainly, having it create no-access dirs for the user isn't desirable. I'm betting that they'd be denied locally as well if my local user didn't have admin override rights. It may be something in the parent directory. --- Nope... can't be, windows doesn't work that way. A directory can affect its contents, but permissions that are inherited can't skip a generation. or fstab mount options. --- I pretty much use the default: # /etc/fstab # #This file is read once by the first process in a Cygwin #process tree. To pick up changes, restart all Cygwin #processes. For a description #see https://cygwin.com/cygwin-ug-net/using.html#mount-table # This is default anyway: none / cygdrive binary,posix=0,user 0 0 Needs a more thorough investigation. But I think it would easily be avoided by a saner directory layout. --- What is more sane, ignoring a problem that was opted out of for 20 years, or understand what causes problems. I can't speak for Windows 10, but through Windows 7, especially in the X64 world, it makes little to no sense to cut your cygwin tools off from being able to access and work on your windows installation. If you have ever boot to a rescue system running from your hard drive -- you have the choice of using all your cygwin tools to recover your system, or to just use Windows tools. If you have 30+ years of unix/linux/posix experience with linux/posix tools, does it make any sense to throw that away when trying to recover your system? X64 Cygwin tools work natively when installed at root. Many of the Windows tools are still x32 which won't run on a rescue system. Linux xfs has 2 acls on directories -- one for the directory and one that can be the default for contents to inherit. It's not identical to windows, but it is similar and if you understand one, the other isn't that different. Cygwin has placed the most emphasis on POSIX compatibility vs. Windows compatibility. In some places it could have been more Windows compatible and still achieved POSIX compat. I do know, that if you have several added Deny acls added to every file, it can mess up default inheritance on content files. What windows has added to the mix has to be deleted -- special perms for creators (user+group). It's similar to default perms in linux, but it isn't the same. It is messed up, other devs have said so -- cygwin perms will conflict with windows perms when they are mixed. They've never tried to fix that. The result are utilities and permissions that have 'no access' set for 'creators' (usually owners). That's not a desired feature unless you opt out of using the windows GUI. But that's the main reason I use it, so what's the point? In any event, I know there are bugs in cygwin, but I don't care enough + know enough about windows development to fix them. That doesn't mean I opt out of using Cygwin or Windows (if I can help it), but it doesn't mean I won't report problems or bugs when I encounter them (doesn't mean I will either, depends on time). Anyway...opting out of understanding why things are or work they way they do is not something I can easily do, by nature. I'm too curious. (too much so, for the time I have to deal with things!). :-) Linda -- 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
