[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.2
Hi Cygwin friends and users, I released a new TEST version of Cygwin, 2.4.0-0.2. There are two changes compared to 2.4.0-0.1: - There was a bug in evaluating the effective user permissions from a Windows ACL, accidentally only creating correct effective permissions for the owner of the file, but not for any other user account in the ACL. This is fixed now. - As outlined in https://cygwin.com/ml/cygwin/2015-11/msg00146.html I now added a shortcut, skipping evaluating the effective permissions if the user already has more permissions than the sum of all group and "other" permissions in the ACL. This should result in a bit faster evaluation of POSIX permissions in some cases by not calling the slow Authz functions at all. == If this code is acceptable, I will create an official 2.4.0 release in about two weeks. == This is the "new POSIX ACL handling reloaded" release. In local testing I successfully integrated AuthZ into the current Cygwin code to generate more correct user permissions by being able to generate effective permissions for arbitrary users. This success convinced me that it might be possible to pick up the POSIX permission rewrite originally targeted for the 2.0.0 release and try to update it using AuthZ and generally revamp it to reflect effective permissions better. My local testing looks good, but this is a major change, so this code really needs a lot more testing in various scenarios. Especially some Windows ACLs created in corporate environments are often a hard nut to crack, and the example from https://cygwin.com/ml/cygwin/2015-04/msg00513.html which was the ultimate downfall of the original implementation is the stuff which needs some good testing. There's, as usual, a downside: AuthZ leans a bit to the slow side. Cygwin caches information already gathered once on a per-process basis, but in locally crafted worst case scenarios (`ls' on lots of file owned by lots of different users and groups) the slowdown may be up to 25%. But that's really just a worst case, in the usual scenarios the slowdown should be mostly unnoticable. To alleviate the problem, the AuthZ code is fortunately only called for non-Cygwin ACLs and Cygwin ACLs created before this release. Within a pure Cygwin environment (e.g., some build directory only used with Cygwin tools) AuthZ should be practically unused. Apart from the aforementioned code changes to "just do it right", there are two additional changes I implemented for this new POSIX ACL revamp release: - I reverted the questionable change I added to 2.0.0-0.7 in terms of chmod group permission handling. The original description of this change was: If you have a non-trivial ACL with secondary accounts and thus a mask value, chmod is supposed to change only the mask, not the permissions of the primary group. However, if the primary group has few permissions to begin with, the result is really surprising. ls -l would, e.g., show read/write perms for the group, but the group might still have only read perms. Personally I find this chmod behaviour really, really bad, so I took the liberty to change it in a way which gives a much less surprising result: If you call chmod on a non-trivial ACL, the group permissions will be used for the primary group and the mask. - setfacl(1) now accepts the combination of the -b and -k options, just as on Linux. As for the description what this implementation strives for, please see http://linux.die.net/man/5/acl What's new: --- - New, unified implementation of POSIX permission and ACL handling. The new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and they allow to inherit the S_ISGID bit. ACL inheritance now really works as desired, in a limited, but theoretically equivalent fashion even for non-Cygwin processes. To accommodate Windows default ACLs, the new code ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. The new code now handles the S_ISGID bit on directories as on Linux: Setting S_ISGID on a directory causes new files and subdirs created within to inherit its group, rather than the primary group of the user who created the file. This only works for files and directories created by Cygwin processes. What changed: - - setfacl(1) now allows to use the -b and -k option combined to allow reducing an ACL to only reflect standard POSIX permissions. Have fun, Corinna -- Corinna Vinschen
Re: Unwanted case-insensivity in file name globbing
Seems overly complicated for me. My current fstab looks like this: # /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 # Device- Mount- FS-type Options Ignored # name point # - --- --- --- C:/Users/home ntfsbinary,posix=1,user 0 0 none/ cygdrivebinary,posix=0,user 0 0 If I remember correctly the cygdrive thing is what automatically maps all my C:. D:, E:, etc drives to /C, /D, E and so on. The magic with posix is described here: https://cygwin.com/cygwin-ug-net/using.html#mount-table posix=0 - Switch off case sensitivity for paths under this mount point (default for the cygdrive prefix). posix=1 - Switch on case sensitivity for paths under this mount point (default for all other mount points). Regards, On 10 November 2015 at 04:15, Paul wrote: > I just replicated my Cygwin setup on Win 7 (64 bits) onto another Win 7 64- > bit machine, including /etc/fstab > >c: /c ntfs binary,posix=0,user,auto >d: /d ntfs binary,posix=0,user,auto >e: /e ntfs binary,posix=0,user,auto >f: /f ntfs binary,posix=0,user,auto >g: /g ntfs binary,posix=0,user,auto >i: /i ntfs binary,posix=0,user,auto >o: /o ntfs binary,posix=0,user,auto >r: /r ntfs binary,posix=0,user,auto >s: /s ntfs binary,posix=0,user,auto > > So my home directory "~" is "C:\cygwin64\home\My.User.Name". > > I noticed that when I issue a command involving a file name pattern, it is > not case sensitive in that directory. For example, "ls -d [A-Z]*" will > return the folder "cat". Web searching revealed that it could be the bash > shell option nocaseglob, but I confirmed that in my case, it is not set: > >$ shopt -p nocaseglob > > shopt -u nocaseglob > > I am also puzzled by the fact that when I cd to a subdirectory, the > unwanted case insensivity is no longer present. I thought that I did > something wierd in replicating my Cygwin setup, but when I tested my > original setup on the 1st computer, I found the same selective case > insensitivity. > > What other setting might cause this? How can I get bonafide Unix behaviour > in the file name globbing? > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unwanted case-insensivity in file name globbing
Jan Bruun Andersen jabba.dk> wrote: | Seems overly complicated for me. My current fstab looks like this: | | # /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 | | # Device- Mount- FS-type Options Ignored | # name point | # - --- --- | --- | | C:/Users/home ntfsbinary,posix=1,user 0 0 | none/ cygdrivebinary,posix=0,user 0 0 | | If I remember correctly the cygdrive thing is what automatically maps | all my C:. D:, E:, etc drives to /C, /D, E and so on. | | The magic with posix is described here: | https://cygwin.com/cygwin-ug-net/using.html#mount-table | | posix=0 - Switch off case sensitivity for paths under this mount point | (default for the cygdrive prefix). | | posix=1 - Switch on case sensitivity for paths under this mount point | (default for all other mount points). Thanks, Jan. I was actually looking at that page, and totally glossed over the posix switch. Will try it (the machine is elsewhere). I realize that cygdrive maps all the letter drives, but I'm trying to cut down on the typed text. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unwanted case-insensivity in file name globbing
On 11/10/2015 10:44 AM, Paul wrote: Jan Bruun Andersen jabba.dk> wrote: | Seems overly complicated for me. My current fstab looks like this: | | # /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 | | # Device- Mount- FS-type Options Ignored | # name point | # - --- --- | --- | | C:/Users/home ntfsbinary,posix=1,user 0 0 | none/ cygdrivebinary,posix=0,user 0 0 | | If I remember correctly the cygdrive thing is what automatically maps | all my C:. D:, E:, etc drives to /C, /D, E and so on. | | The magic with posix is described here: | https://cygwin.com/cygwin-ug-net/using.html#mount-table | | posix=0 - Switch off case sensitivity for paths under this mount point | (default for the cygdrive prefix). | | posix=1 - Switch on case sensitivity for paths under this mount point | (default for all other mount points). Thanks, Jan. I was actually looking at that page, and totally glossed over the posix switch. Will try it (the machine is elsewhere). And don't forget about the registry setting you need in order to turn on case sensitivity: https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unwanted case-insensivity in file name globbing
Ken Brown cornell.edu> wrote: > ...don't forget about the registry setting you need in order to turn > on case sensitivity: > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames- casesensitive That's OK, I just need case-insensitive file globbing. I don't want to mess with the actual case sensitivity in Win 7 cuz who knows consequences (human or software) can result. Besides, I don't have permissions to change the registry, though I appreciate the awareness. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Recent change to terminal icon / mintty breaks taskbar pinning
I recently updated to the latest set of cygwin packages, and something has broken the terminal icon when pinned to the start menu. When starting from the Start menu "Cygwin Terminal" icon, mintty comes up normally, loads my user profile, and the cwd is set to ~. However, if I right-click the icon on the taskbar and select "Pin to taskbar", close the existing terminal, then open by clicking on the pinned taskbar icon, the terminal starts but it does not load the profile, the cwd is /usr/bin, and no commands can be found (e.g. ls: command not found). I have tracked this down to the pinned icon missing the arguments "-i /Cygwin-Terminal.ico -". I'm sure this worked prior to the update, so something seems to have changed. I update fairly often, so this is something recent within the past month or so. I'm on Windows 8.1 x64 using Cygwin 32bit. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent change to terminal icon / mintty breaks taskbar pinning
Greetings, Brian Mathis! > I recently updated to the latest set of cygwin packages, and something > has broken the terminal icon when pinned to the start menu. When > starting from the Start menu "Cygwin Terminal" icon, mintty comes up > normally, loads my user profile, and the cwd is set to ~. > However, if I right-click the icon on the taskbar and select "Pin to > taskbar", close the existing terminal, then open by clicking on the > pinned taskbar icon, the terminal starts but it does not load the > profile, the cwd is /usr/bin, and no commands can be found (e.g. ls: > command not found). I have tracked this down to the pinned icon > missing the arguments "-i /Cygwin-Terminal.ico -". > I'm sure this worked prior to the update, so something seems to have > changed. I update fairly often, so this is something recent within > the past month or so. I'm on Windows 8.1 x64 using Cygwin 32bit. I've experienced this same issue across a wide range of applications, including AD management tools. I have a feeling this is unrelated to Cygwin. -- With best regards, Andrey Repin Wednesday, November 11, 2015 06:52:19 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Octave audio issues reading wav files
I have a 32 bit install with a possible audio issue in Octave 4.0.0-2.
My primary machine is unavailable right now but I think I can come up with a
STC from memory.
wavread("somefile.wav")
leads to a message about missing sndfile and that audioinfo can't work.
The issue seems to be octave was built on a machine without libsndfile so
config.h
sets HAS_SNDFILE to 0 which causes audioinfo to fail. A quick look at
audioinfo source
shows that most of the function is skipped unless HAS_SNDFILE is true.
I tried building local to check my theory out but ran into another possible
issue.
It seems libqrupdate 1.1.2-1 may have a problem.
/usr/lib/libqrupdate.la seems to (internally) include dependencies on files:
/usr/lib/liblapack.la and /usr/lib/libblas.la
which don't exist so local builds fail with something like:
/usr/bin/grep: /usr/lib/liblapack.la file does not exist
If any of the above is wrong or confused I will be happy to back up and
provide cygcheck and generally better
information.
Stan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
