Re: XWin dpi setting not working?
Wei Ku hotmail.com> writes: > My recently purchased laptop has a rather high resolution 3200x1800, > corresponding to roughly 300 dpi. Consequently, everything looks tiny in > the default setting of the Cygwin X server. Adding an option "-dpi 300" to XWin > XWin does not seem to have any effect. (The cygserver is enabled.) Can a > any one please advise how to solve / workaround this issue? Thanks in a > advance for the great help. If the monitor reports the correct physical dimensions of the screen, then the dpi are usually determined correctly without any manual intervention (note that in some cases the physical dimensions are "faked" to get integer multiples of 96dpi or to set the pixel aspect ratio to 1:1). Your expectation that somehow that DPI setting will influence the presentation of X applications is on shaky ground, however. HiDPI support for X11 is rudimentary at best and many applications use bitmap fonts or fixed resolution graphics by default. You may try to use a scaled display (either 2:1 or 3:1 in your case) or if you know which applications you are going to use fiddle with their defaults to adapt them to your display better. https://wiki.archlinux.org/index.php/HiDPI Regards, Achim. -- 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
Is there something going on with the ML server?
On behalf of Corinna, who says on IRC that her messages don't make it to the mailing lists (regular, announce, nor overseers), is she getting detected as spam now (and why)? Or is there some more global issue? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Windows 10 error message
On opening Cygwin for the first time in Windows 10, I get the message: 0[main] bash 8428 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to ... I get every time I open Cygwin. Lou -- 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: Windows 10 error message
On 16/12/2015 16:19, jrsyangl wrote: On opening Cygwin for the first time in Windows 10, I get the message: 0[main] bash 8428 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to ... I get every time I open Cygwin. Lou -- which version are you running ? (eg "uname -a" output) That issue should have been solved years ago If latest, not please follow guidelines specified at: Problem reports: http://cygwin.com/problems.html "Run cygcheck -s -v -r > cygcheck.out and include that file as an attachment in your report. Please do not compress or otherwise encode the output. Just attach it as a straight text file so that it can be easily viewed. " Regards Marco -- 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: Is there something going on with the ML server?
On 2015.12.16 10:22, David Macek wrote: On behalf of Corinna, who says on IRC that her messages don't make it to the mailing lists (regular, announce, nor overseers), is she getting detected as spam now (and why)? Or is there some more global issue? -- David Macek Her message to the announce list "TEST RELEASE: Cygwin 2.4.0-0.11" dated 2015.12.16 06:39 made it through this morning. Jack -- 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
my mails to the cygwin ML disappear
For some reason my mails to the cygwin mailing list either disappear or bounce. So I'm just testing if mail gets through at all... Corinna -- 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: SegFault running "ls -l" after Microsoft Patch Day
Hi Rainer, On Dec 15 20:29, Dr Rainer Woitok wrote: > Corinna, > > On Monday, 2015-12-14 15:05:32 +0100, you wrote: > > > find: './System Volume Information': Permission denied > > > > This is normal if you don't run your shell elevated. Try again in an > > elevated shell. > > Hm. I have several NTFS formatted USB sticks and a script which keeps > them up to date by -- among other things -- running a "find" command > against their mount points. Until Tuesday this script never complained > about a "./System Volume Information" directory, but since Wednesday it > does. If you are saying complaints regarding protected system files are > normal for an unprivileged Cygwin user, one of these patches must have > freshly created these directories on Wednesday when I plugged in the USB > sticks. At least the modification dates of the "./System Volume Inform- > ation/" directories on these USB sticks do not contradict this theory. That's ok. Given the nature of this folder the OS will create it if it thinks it needs it. > I'll try to remove these directories on the USB sticks as soon as this > issue is solved somehow. Ultimately the OS will probably recreate the dir at one point depending on your system settings. http://blogs.msdn.com/b/oldnewthing/archive/2003/11/20/55764.aspx >Since my "/etc/passwd" file > uses more Unix like names even for the typical Windows accounts, Which doesn't make much sense from my POV, but, anyway. As long as the entries are correct. > I then > ran these commands with an additional "-n" option to produce less con- > fusing listings, ... and low and behold, now all five commands succeed- > ed in BOTH, the privileged and the unprivileged shell! > > I then inspected my "/etc/passwd" file and removed the last line from > it, which I had added long ago to fight the "Unknown+User" and "Unknown+ > Group" entries in the "ls -l" output: > >other:*:4294967295:4294967295::: Ouch! > Now all five commands above succeed for the privileged user (though with > an ouput cluttered with "Unknown+*" entries :-), and at least the normal > "ls -l /C" command now also succeeds for the unprivileged user, while > the other four "ls -ld" commands are still segfaulting. Finally, I also > removed the corresponding line > >other:*:4294967295: Ouch, ouch! I'm probably not paranoid enough for this job. The above are invalid passwd and group entries. passwd and group files *main* job is to map a Windows SID to a Cygwin uid/gid. Apart from the obvious fact that both files are not required anymore, the above entries will lead to an invalid SID stored for an account called "other". The questions you should ask yourself: Why are there SIDs unknown to Cygwin, despite Cygwin fetching account info directly from Windows? Apart from the explanation in https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how, there are files in the top level directory of your drive way which disallow non-admin users to read the file's security information, thus Cygwin can't fetch the owner and group SIDs, thus the SIDs are "Unknown". However, start the shell elevated and you'll see that most of the files are owned by "SYSTEM" or "TrustedInstaller". Only pagefile.sys, swapfile.sys and (I think) hiberfile.sys are locked exclusively by the OS, so even an admin user can't read the security descriptor. The bottom line is, by adding the aforementioned entries to /etc/passwd and /etc/group you not only create invalid passwd and group entries which only work by happenstance, you also hide the *real* information from yourself, even if you're running an elevated shell. To me this sounds like a bad idea. Personally I rather see what's really there. > from my "/etc/group" file and -- you guessed it -- now everything works > in both, elevated and normal shell. Sigh. Good! > What is still missing is some sort of explanation. How can a Windows > patch cause these two lines in files "/etc/passwd" and "/etc/group" to > fail working, and why is the effect different, depending on privilege > status? (Remember: I first applied Windows patches, then I ran into > problems, and finally I updated Cygwin). Well, *shrug*. > > ... > > > $ ls -lF /C > > > Segmentation fault (core dumped) > > > $ > > > > I can't reproduce this one. > > Perhaps you can now with this additional information :-) Yes. The OS function RtlCopySid crashes trying to read an invalid SID structure. I applied a fix and uploaded a new developer snapshot to https://cygwin.com/snapshots/ and created a new test release 2.4.0-0.11 for testing. Please give any of them a try. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQwizSxFttJ.pgp Description: PGP signature
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11
Hi Cygwin friends and users, I released TEST version 2.4.0-0.11 of Cygwin. So 0.10 was *not* the last test release... Anyway, compared to 0.10 there's only a single change: - Fix a potential crash reading invalid passwd and group entries from /etc/passwd and /etc/group. Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html Since 0.10 was such a short-lived release, here's the list of changes from 0.9 to 0.10 again: - The header file layout has been cleaned up, mostly in terms of the sys/select.h, sys/signal.h and sys/types.h files. This is a generic change in newlib and aligns the affected headers more closely to the FreeBSD layout. - A potential locking problem has been fixed in newlib, which may affect fclose and freopen calls under FSETLOCKING_BYCALLER conditions. - Another potential deadlock problem has been fixed which could occur in atexit handling under low memory conditions. - A new mount type "usertemp" has been introduced, which allows to mount a POSIX directory to the Windows per-user temporary directory: none /tmp usertemp binary,posix=0 0 0 == Due to the imminent holiday schedule, I postponed the official release of Cygwin 2.4.0 to early 2016. Testing is still highly appreciated... == 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 standard Windows ACLs, the POSIX permissions of the owner and all other users in the ACL are computed using the Windows AuthZ API. This may slow down the computation of POSIX permissions noticably in some circumstances, but is generally more correct. The new code also 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
Re: my mails to the cygwin ML disappear
On Dec 16 16:56, Corinna Vinschen wrote: > For some reason my mails to the cygwin mailing list either disappear > or bounce. So I'm just testing if mail gets through at all... Seems to work again. Puh! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpncjdqwQ68Y.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11
Corinna Vinschen cygwin.com> writes: > > Hi Cygwin friends and users, > > I released TEST version 2.4.0-0.11 of Cygwin. > > So 0.10 was *not* the last test release... > > Anyway, compared to 0.10 there's only a single change: > > - Fix a potential crash reading invalid passwd and group entries from > /etc/passwd and /etc/group. > Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html Works beautifully on Win 10 x64 10586.29. Regards, ismail -- 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
[ANNOUNCEMENT] Updated: subversion-1.8.15-1
NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.15/CHANGES for more details about the changes in 1.8.15. This release changes mod_dav_svn to no longer map requests to the local filesystem. Administrators of mod_dav_svn servers should read the section about this in the release notes: http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org Trespassers will be shot. Survivors will be prosecuted. -- 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
[ANNOUNCEMENT] Updated: subversion-1.9.3-1
SECURITY: = This release fixes two security issues: CVE-2015-5259: Remotely triggerable heap overflow and out-of-bounds read caused by integer overflow in the svn:// protocol parser. http://subversion.apache.org/security/CVE-2015-5259-advisory.txt CVE-2015-5343: Remotely triggerable heap overflow and out-of-bounds read in mod_dav_svn caused by integer overflow when parsing skel-encoded request bodies. http://subversion.apache.org/security/CVE-2015-5343-advisory.txt NEWS: = Please see the release notes http://subversion.apache.org/docs/release-notes/1.9.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.9.3/CHANGES for more details about the changes in 1.9.3. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org Cats, no less liquid than their shadows, offer no angles to the wind. -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11
On 12/16/2015 11:48 AM, Corinna Vinschen wrote: > - The header file layout has been cleaned up, mostly in terms of the >sys/select.h, sys/signal.h and sys/types.h files. This is a generic >change in newlib and aligns the affected headers more closely to >the FreeBSD layout. These changes are leading to lots of errors when building emacs: /usr/include/cygwin/signal.h:178:3: error: unknown type name ‘pthread_attr_t’ /usr/include/cygwin/signal.h:213:3: error: unknown type name ‘pid_t’ /usr/include/cygwin/signal.h:230:2: error: unknown type name ‘timer_t’ /usr/include/sys/signal.h:211:6: error: #error You need the winsup sources or a cygwin installation to compile the cygwin version of newlib. /usr/include/sys/signal.h:214:5: error: unknown type name ‘pthread_t’ /usr/include/sys/time.h:104:34: error: unknown type name ‘u_int’ [... and many more] 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
