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'm familiar with POSIX ACL's. > 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!). The reasoning for things to work like that is well explained in the documentation. Though, if you have found a special case that should be avoided, and it looks like so, things may improve with your help. -- With best regards, Andrey Repin Friday, July 16, 2021 7:11:36 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
