Re: wildcards don't work in directory with files with odd characters
On Mon, May 18, 2020 at 8:07 PM Adam Dinwoodie wrote: > Cygwin's `ls` expects the > shell (e.g. Bash) to expand globs like `*`, but Windows' command > prompt expects applications to handle expanding globs (or the Windows > equivalents thereof) themselves. When you call a Cygwin command like > `ls` directly from the Windows command prompt, Windows passes the > arguments as-is to the Cygwin command, and the Cygwin command assumes > that the arguments it received are already appropriately expanded. This is actually false. The official FAQ mentions it as well here<https://cygwin.com/faq.html#faq.api.globbing>. I went on to investigate what's the issue, but I can't replicate it. Things like the console code page, the system code page<https://www.digitalcitizen.life/changing-display-language-used-non-unicode-programs> could be at play, but I don't see why it would behave like this. -- David Macek -- 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: Groups command failing me in Windows 10
I found a few old references to incorrect ordering on the Internet, but the alleged solutions of using `noacl` don't explain much. The Cygwin user guide does explain it, but I guess it doesn't contain the right keywords for Google to find it. See <https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files>, especially this part: > This works on all supported versions of Windows. Only the GUIs aren't able > (or willing) to deal with that order. -- David Macek -- 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: Very dangerous hacking ? Surprising relationship between cygwin and Microsoft
> To conclude, Microsoft spy and register all sites you access, cygwin.com in > particular. > I hope only with Edge, but I am not sure of that. Unless I missed something in your report, I cannot agree with your conclusion. *Windows* storing something in the registry does not imply *Microsoft* receives or processes that information. -- David Macek -- 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: Invalid request code when removing files
I would ask about your Cygwin and Windows versions, but unless you're running an Insiders build, I don't think WSL is supposed to be this broken. Are you by any chance running a third-party antivirus or security suite or some uncommon driver, file system software? Consult the BLODA<https://cygwin.com/faq/faq.html#faq.using.bloda> for the worst offenders, but note that this list is not exhaustive. -- David Macek -- 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: Cygwin fails to utilize Unicode replacement character
On 4. 9. 2018 16:18, Thomas Wolff wrote: My vote is against the patch because the nodef glyph will often be just blank space which is certainly worse than ▒. How often is "often"? Do the default Windows fonts have okay nodef glyphs? By the way, how does this work with OEM fonts? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Cygwin fails to utilize Unicode replacement character
On 4. 9. 2018 11:00, Corinna Vinschen wrote: We either keep 0xfffd now and the user gets the nodef glyph, or I revert the patch and let the console print 0x2592 MEDIUM SHADE again. Decision has to be made today. I will release 2.11.1 tomorrow. I vote for keeping the patch and printing 0xFFFD. It's okay in the default case, it's exactly what was requested in the non-standard font case and it's future proof in case ConHost implements rendering using fallback fonts. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Why is stdin always a pipe?
Hi. I see this: $ [[ -p /dev/stdin ]] && echo pipe || echo nopipe nopipe $ [[ -t /dev/stdin ]] && echo term || echo noterm noterm Am I missing something? I tested various scenarios and stdin is never a pipe, neither a tty for me. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Fails to launch batch script in some directories
On 21. 4. 2018 17:38, Brian Inglis wrote: See my other post in this thread where strace shows @ handling is not involved, as the script directory and name are normalized and converted to a win32 path correctly, but child_info_spawn::worker does not appear to quote args with spaces (or apostrophes) when building the command line, despite the comment near the top of the function. Do you have a test case for this? In my testing, paths with spaces (like 'x y' instead of '@ x') work just fine. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Fails to launch batch script in some directories
Whoa, an interesting bug. I'm forwarding this to the Cygwin mailing list for reference. I might take a deeper look over the weekend if no-one beats me to it. It seems like running batch files (.bat, .cmd) inside a directory with an at sign and a space (such as '@ x' or 'x @') fails. /w/temp/@ x$ ./hello.bat 'W:\temp\@' is not recognized as an internal or external command, operable program or batch file. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: GitForWindows vs. Cygwin
It doesn't use cygwin, therefore it's not related. Since this is a cygwin mailing list, that means the first two replies were correct — this isn't the place to discuss it. When the vast majority of the code in the MSYS2 runtime is exactly the same as the code in the Cygwin runtime, and Git for Windows uses msys-2.0.dll in a number of places (which is essentially a renamed copy of cygwin1.dll) the question was fair. Particularly given Cygwin has its own git package, it's only natural to wonder how that differs from Git for Windows, and how it differs from the probably lesser- known msys2-git package (which is built in very nearly the same configuration as the Cygwin git package, posix style). Only GfW and Msys2 Git projects can answer how Cygwin components are used by their projects. Most (all?) of Cygwin winsup and (all of?) newlib are available under permissive BSD(-style) licences that allow all uses of the code. It's possible that the developers of those GfW and Msys2 Git packages have moved on from those projects and the current maintainers don't have the basis to answer. One might expect some of those maintainers to be subscribed to this list and able to answer, but they may not, and just check web archives, or they may choose not to get into this discussion here, although they could perhaps suggest a more appropriate forum, or take the discussion off-list. I've been watching this thread closely, but I had decided not to post since it seemed like this discussion is unwanted by a part of the community. On the surface, this discussion is about Git, so the most on-topic place to discuss is the Git public mailing list. I personally don't think the Cygwin mailing list is off-topic. Because most(all?) Windows Git distros use Cygwin code, it might be even more useful to ask here (though I assume Johannes subscribes to Git ML and he would be able to answer all the intricacies pretty accurately). So far, Tony Kelman's descriptions were pretty spot on (that's why I didn't respond to his call for corrections -- I couldn't think of any). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Challenge: a VERY strange problem with command substitution in bash
On 4. 12. 2017 14:01, Erik Haukjær Andersen wrote: Hello I have seen a similar problem on Windows 7, using Cygwin bash version 4.4.12(3)-release (x86_64-unknown-cygwin). After repeating a simplified test on my own host and 6 other colleagues, my conclusion is that the cause is found in BeyondTrust SecureDesktop, which you also may have installed (I saw you wrote something about TrustedInstaller). I have raised an internal case with my IT service desk to resolve the issue (and see what they can do). My understanding is that you're just reporing your findings, not asking for support here. Assuming that's the case, the only thing to do here is to add this to the BLODA. I actually can't find any mention of a product nor feature called SecureDesktop, so unless there are better ideas, let's do only "BeyondTrust". -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: sort utility goes berzerk (x86_64)
On 30. 11. 2017 1:44, Houder wrote: ntoskrnl.exe!memset+0x61a ntoskrnl.exe!KeWaitForMultipleObjects+0xd52 ntoskrnl.exe!KeWaitForSingleObject+0x19f ntoskrnl.exe!PoStartNextPowerIrp+0xbd0 < ? ntoskrnl.exe!PoStartNextPowerIrp+0x186d < ? cygwin1.dll!reent_data+0x5f0 cygwin1.dll!acl_get_perm+0x9aa1 cygwin1.dll!_getreent+0x1097 sort.exe+0x5319 sort.exe+0x103e0 cygwin1.dll!cygwin_dll_init+0x11c2 cygwin1.dll!setprogname+0x35c3 cygwin1.dll!setprogname+0x3674 In my experience, stack traces of Cygwin from MS tools are not very realiable. Can you try GDB as well? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Mailing list threads [was: gawk 4.1.4: CR separate char for CRLF files]
Please stop breaking the message threads, it's hard to comprehend what's happening this way. If needed, I can help with configuring your e-mail client. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: format=flowed issues [Was: gawk 4.1.4: CR separate char for CRLF files]
On 11. 8. 2017 1:59, Steven Penny wrote: On Thu, 10 Aug 2017 16:48:47, Brian Inglis wrote: Many archives and sites display lines off the right margin instead of allowing them to wrap as normal in HTML. Possibly using pre format style without horizontal scrollbars instead of just specifying a monospace font style. That makes it a site or converter design issue! Nope. Wrong. David has been doing this for over 2 years: http://cygwin.com/ml/cygwin/2015-01/msg00232.html So it is a user issue. The user must hard wrap because Cygwin site does not. """ Nope. Wrong. Cygwin site has been doing this for over 2 years: http://cygwin.com/ml/cygwin/2015-01/msg00232.html So it is a site issue. The site must wrap because David does not. """ In other words, why do you think your argument is correct? Format=flowed is not a new thing<https://www.ietf.org/rfc/rfc2646.txt> and it would be nice if the archives site could display it correctly. I can cooperate on this with the maintainer(s) if they're interested. Essentially, one line of CSS should fix it, judging by my quick test. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: gawk 4.1.4: CR separate char for CRLF files
On 10. 8. 2017 14:04, cyg Simple wrote: The clue here is, does it only work for this type of OS? If yes then it isn't portable anyway but should it be? And does it only work on this type of OS because of an issue that could change as a result of a fix. Cygwin has always been and will always be a work in progress. The rule of thumb "does it work on Linux" should be applied to all that you do with Cygwin. If it only works on Cygwin and not on Linux then the chances are, something will change. I feel the need to correct you slightly. Although Linux is a good model, Cygwin primarily strives to be a good *POSIX* platform, so there may be cases where the two intentionally differ. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: when using cygwin version 2.8.2 the behavior of CR/LF changed completely compared to previous versions
On 2. 8. 2017 17:34, Roger Krebs wrote: Hi, after updating from version 1.7.33 to version 2.8.2 the behavior of CR-LF handling completely changed. This results in several srcipt errors etc. See announcements: * <https://cygwin.com/ml/cygwin-announce/2017-02/msg00036.html> for sed * <https://cygwin.com/ml/cygwin-announce/2017-02/msg00035.html> for grep * <https://cygwin.com/ml/cygwin-announce/2017-02/msg00034.html> for gawk There was also a discussion about these changes at <https://cygwin.com/ml/cygwin/2017-06/msg00040.html>. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
On 31. 7. 2017 23:13, Corinna Vinschen wrote: Ah, no, no, no. I found the problem. When using CP 65001 on pre-W10, you *must not* use the ANSI functions PeekConsoleInputA and ReadConsoleInputA, but select() was still using them as it did so for ages. Now using the UNICODE functions PeekConsoleInputW and ReadConsoleInputW, select is doing the right thing even with CP 65001. Awesome. Confirming that the new snapshot allows ö to be input in plain bash with CP 65001. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
On 31. 7. 2017 14:36, David Macek wrote: On 31. 7. 2017 11:48, Corinna Vinschen wrote: Well, it works for me. I tested this in tcsh, bash and od on Windows 10. I tested on Windows 2012 R2 (8.1 equivalent) and I can confirm Steven's findings. Tried with an older installation and then once more after a complete update (`uname -a`s below). - CYGWIN_NT-6.3 computername 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin - CYGWIN_NT-6.3 computername 2.8.2(0.313/5/3) 2017-07-12 10:58 x86_64 Cygwin - Alt 148 outputs nothing - Alt 0246 outputs nothing - Pasting this character does not work I ran Cygwin from a clean command window (`cmd /d`) using `chcp ...` and `bin\bash -li`. The ö's don't appear in bash with CP 65001. Other combinations (bash with CP 437, cmd with either CP) allow ö's to appear. Try the legacy console (conhost v1), if you haven't already. Maybe it will show the same behavior even on Windows 10. Oh, and after reading through the whole thread, I realize I should add that I've set Consolas as my font. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
On 31. 7. 2017 11:48, Corinna Vinschen wrote: Well, it works for me. I tested this in tcsh, bash and od on Windows 10. I tested on Windows 2012 R2 (8.1 equivalent) and I can confirm Steven's findings. Tried with an older installation and then once more after a complete update (`uname -a`s below). - CYGWIN_NT-6.3 computername 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin - CYGWIN_NT-6.3 computername 2.8.2(0.313/5/3) 2017-07-12 10:58 x86_64 Cygwin - Alt 148 outputs nothing - Alt 0246 outputs nothing - Pasting this character does not work I ran Cygwin from a clean command window (`cmd /d`) using `chcp ...` and `bin\bash -li`. The ö's don't appear in bash with CP 65001. Other combinations (bash with CP 437, cmd with either CP) allow ö's to appear. Try the legacy console (conhost v1), if you haven't already. Maybe it will show the same behavior even on Windows 10. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Avast has put 2 Cygwin files in its chest
On 4. 5. 2017 11:33, Alex Brega wrote: > Would be possible for you to provide me these files (dbus-daemon.exe and > ssh.exe) via mail or uploaded somewhere in order to recover them on their > original folders ? The installer can re-install any broken packages, including those containing ssh.exe and dbus-daemon.exe. The installer is available at <https://cygwin.com/install.html>. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Windows 10 Creators Update and Symlinks
> ver Microsoft Windows [Version 10.0.15063] $ uname -a CYGWIN_NT-10.0 mew 2.8.1(0.310/5/3) x86_64 Cygwin === Developer mode DISabled, non-elevated Administrators account > echo > foo > mklink bar foo You do not have sufficient privilege to perform this operation. $ export CYGWIN="winsymlinks:nativestrict" $ touch foo $ ln -s foo bar ln: failed to create symbolic link 'bar': Operation not permitted === Developer mode ENabled, non-elevated Administrators account $ export CYGWIN="winsymlinks:nativestrict" $ touch foo $ ln -s foo bar $ rm bar > echo > foo > mklink bar foo symbolic link created for bar <<===>> foo > del bar -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 13. 4. 2017 16:24, David Macek wrote: > On 13. 4. 2017 14:34, Chevallier Yves wrote: >> I get a very different behaviour with `cygpath` after I upgrade my version >> of Cygwin. Why? and how can I fix it? >> >> With Cygwin 2.7: >> >> ``` >> $ uname -a >> CYGWIN_NT-6.1-WOW CPT 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin >> $ cygpath --version >> cygpath (cygwin) 2.7.0 >> >> $ cd / >> $ touch foo.exe >> $ cygpath -m foo >> foo.exe >> >> $ cd >> $ touch foo.exe >> $ cygpath -m foo >> foo >> ``` > > I can't reproduce this. I see both as `foo` on Cygwin (and both as `foo.exe` > on MSYS2). Can you post the output of your `mount`, also `ls foo*` from both > directories? My mistake, I was using Cygwin v2.5.x. I updated to v2.8.0 and now I see both as `foo.exe`. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: cygpath compatiblity break (v2.1 -> v2.7)
On 13. 4. 2017 14:34, Chevallier Yves wrote: > I get a very different behaviour with `cygpath` after I upgrade my version of > Cygwin. Why? and how can I fix it? > > With Cygwin 2.7: > > ``` > $ uname -a > CYGWIN_NT-6.1-WOW CPT 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin > $ cygpath --version > cygpath (cygwin) 2.7.0 > > $ cd / > $ touch foo.exe > $ cygpath -m foo > foo.exe > > $ cd > $ touch foo.exe > $ cygpath -m foo > foo > ``` I can't reproduce this. I see both as `foo` on Cygwin (and both as `foo.exe` on MSYS2). Can you post the output of your `mount`, also `ls foo*` from both directories? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Settings from lang.sh causing garbled output in dialog when run from cmd.exe
On 6. 4. 2017 16:22, Matt D. wrote: > On 4/6/2017 5:47 AM, David Macek wrote: >> Try calling `/proc/cygdrive/c/windows/system32/chcp.com 65001` before >> running `dialog ...`. Does that help? > > It does not. I tried setting the code page to 65001 in cmd and/or after > loading bash as a login shell. Neither solution worked. > > This is very easily reproducible for me just by loading cmd, 'bash --login' > and then running the dialog sample I provided. Thanks for the response. Re-posting back to the mailing list. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Settings from lang.sh causing garbled output in dialog when run from cmd.exe
On 6. 4. 2017 11:39, Matt D. wrote: > Why am I getting garbled output with this line present? Try calling `/proc/cygdrive/c/windows/system32/chcp.com 65001` before running `dialog ...`. Does that help? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.1-1
On 10. 1. 2017 1:39, Steven Penny wrote: > On Sun, 18 Dec 2016 09:41:29, Corinna Vinschen wrote: >> - Fix regression in console charset handling >> Addresses: https://cygwin.com/ml/cygwin/2016-10/msg0.html > > It looks like fixing this may have caused another issue. Example test: > > With cmd.exe, you can type Alt 234 and it produces > GREEK CAPITAL LETTER OMEGA U+03A9. However with Cygwin via Cygwin.bat it > yields > nothing. Non ASCII characters can be read from scripts, but they cannot be > entered interactively. > > They cannot be pasted either; pasting some words will remove all non ASCII > characters. > > I believe this to be a recent issue, if memory serves this did work before, > and > should given that cmd.exe handles it fine. My experience: conhostv2+cmd: Shift+Ins -> ŕ conhostv2+cmd: Alt+234 -> ŕ conhostv2+cygwin260+bash: Shift+Ins -> ŕ conhostv2+cygwin260+bash: Alt+234 -> ŕ conhostv2+cygwin261+bash: Shift+Ins -> ŕ conhostv2+cygwin261+bash: Alt+234 -> (i.e. nothing) conhostv2+cygwin261+bash: Alt+5 -> [G (if there's nothing written yet on the input line, Alt+5 also causes what seems to be ~10-second delay in input processing) mintty+cygwin261+bash: Shift+Ins -> ŕ mintty+cygwin261+bash: Alt+234 -> ê Versions and settings: $ uname -a CYGWIN_NT-10.0 mew 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin $ uname -a CYGWIN_NT-10.0 mew 2.6.1(0.305/5/3) 2016-12-16 11:55 x86_64 Cygwin $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="C.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL= $ /proc/cygdrive/c/Windows/System32/chcp.com Active code page: 65001 Using the font Consolas. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Fwd: Re: DMARC - gmail.com or is it yahoo.com
On 10. 12. 2016 21:39, Christopher Faylor wrote: > On Wed, Nov 30, 2016 at 11:00:12AM -0500, Christopher Faylor wrote: >> On Wed, Nov 30, 2016 at 10:55:49AM -0500, Frank Ch. Eigler wrote: >>> cygsimple wrote: >>>> See the description below of a problem that is occurring because of >>>> DMARC rules in place by yahoo.com. Is there anything you can do for this? >>> >>> cgf, any chance of updating our copy of ezmlm-toaster etc.? >>> Newer-than-2014 versions of ezmlm-idx seem to have some DMARC >>> capabilities. >> >> I started looking at this when it came in. No ETA yet. > > Huh. I thought I sent an update about this but it vanished in the aether. FWIW, I received a message on [Thu, 8 Dec 2016 21:14:41 -0800 (PST)]: > I'm going to use start using a new version of ezmlm-send on Friday. It will > rewrite the From addresses of any domain which wants to use DMARC. From what > I've read, that should stop yahoo and gmail from complaining. > I just turned on a new DMARC-aware version of ezmlm-send which rewrites > the From address for any domain that is DMARC sensitive to something like: > > "User name via mailinglist " > > when the mail is broadcast to the mailing list. I would have done this > sooner but my ezmlm skills were really rusty and I almost ran out of > extremities to shoot. Thanks. By the way, does that include domains with SPF? > Please send any errors or issues encountered to overse...@sourceware.org. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: DMARC - gmail.com or is it yahoo.com
On 29. 11. 2016 15:24, cyg Simple wrote: > I find this excerpt from cygwin-help a bit confusing. Notice the > "yahoo.com" in the "Remote host said:" message. What's really going on > here? Why is yahoo.com doing the authentication for a gmail.com address? > > > Received: (qmail 130602 invoked for bounce); 17 Nov 2016 10:26:04 - > Date: 17 Nov 2016 10:26:04 - > From: mailer-dae...@sourceware.org > To: cygwin-return-2058...@cygwin.com > Subject: failure notice > > Hi. This is the qmail-send program at sourceware.org. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > : > User and password not set, continuing without authentication. > 173.194.202.27 failed after I sent the message. > Remote host said: 550-5.7.1 Unauthenticated email from yahoo.com is not > accepted due to domain's > 550-5.7.1 DMARC policy. Please contact the administrator of yahoo.com > domain if > 550-5.7.1 this was a legitimate mail. Please visit > 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the > 550 5.7.1 DMARC initiative. e69si30940847pfk.231 - gsmtp > > Reading and understanding email bounces is notoriously hard. I got the same email, just with my email address instead of yours. The problem is not related to the recipient's address, but to the sender's address. A quick query to got me the original message that bounced. Its headers follow. > Date: Wed, 16 Nov 2016 04:25:22 -0500 > From: Ian Lambert > To: cygwin@cygwin.com,Marco Atzeri > Subject: Re: Resend: pdfseparate does nothing for me? > Message-ID: <8c630cdb-03cd-4388-b8ac-7c2a033be...@yahoo.com> > MIME-Version: 1.0 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: quoted-printable What happens is that ezmlm (the mailing list software) broadcasts this message (after adding a bunch of links at the bottom) to everyone subscribed, but with the sender unchanged. Yahoo has got a DMARC policy set up that is supposed to ensure that only Yahoo servers can send messages marked as "from ...@yahoo.com". As you can see, Google is enforcing the policy and correctly rejecting the message as fake (it really wasn't sent by Yahoo, but by Sourceware). This is only going to happen more and more often as email providers up the battle against spam. The best solution is to change the way ezmlm re-sends the messages, I bet there's a big discussion about it somewhere on the Internet. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: symbolic linls
On 10. 8. 2016 12:46, Andrey Repin wrote: >>> Windows' symbolic links are typed: they need to know whether they point to >>> a directory or to a file > > This is of no concern for an application. This is actually the worst problem with NTFS symlinks. The symlink becomes unreadable/untraversable if its type doesn't match the target's type. The most prominent example where this is an issue is creating symlinks to non-existent targets. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: symbolic linls
On 10. 8. 2016 3:16, Andrey Repin wrote: > Greetings, David Macek! > >>> As i understand Cygwin will soon no longer support Windows XP resp. >>> 2003. This means that only Windows versions with native symbolic link >>> functionality will be supported after that. Would it be possible to use >>> only native symbolic links throughout esp. during setup.exe? > >> Short answer: No. > >> Long answer: > >> There are limitations to NTFS symlinks, other than OS support, that make >> them incompatible with POSIX symlinks. See >> <https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks> and >> <https://github.com/git-for-windows/git/wiki/Symbolic-Links> for more >> information. > > There's limitations, yes. But what do you mean by "incompatibility" ? I mean differences between how NTFS symlinks work and how POSIX symlinks (that Cygwin apps expect) work. It's described on the Git-for-Windows page I linked. Quoting: > You need the SeCreateSymbolicLinkPrivilege privilege, which is by default > assigned only to Administrators but can be assigned to normal users using > Local Security Policy (or via Active Directory). Note that regardless of > privilege assignment, members of the Administrators group will also require > UAC elevation. > Symbolic links on remote filesystems are disabled by default (call fsutil > behavior query SymlinkEvaluation to find out) > Symbolic links will only work on NTFS, not on FAT > Windows' symbolic links are typed: they need to know whether they point to a > directory or to a file -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: symbolic linls
On 5. 8. 2016 13:24, Franz Fehringer wrote: > Dear Cygwin community, > > As i understand Cygwin will soon no longer support Windows XP resp. > 2003. This means that only Windows versions with native symbolic link > functionality will be supported after that. Would it be possible to use > only native symbolic links throughout esp. during setup.exe? Short answer: No. Long answer: There are limitations to NTFS symlinks, other than OS support, that make them incompatible with POSIX symlinks. See <https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks> and <https://github.com/git-for-windows/git/wiki/Symbolic-Links> for more information. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Midnight Commander is very slow when starting and changing directories
On 25. 7. 2016 17:34, Krzysztof Bociurko wrote: > I have found this issue in a new incarnation - and this time it is NOT > with midnight commander but basic gnu utils. > Again it's the 4 seconds lost. > > $ time ls /cygdrive/ > c d > > real0m4.065s > user0m0.000s > sys 0m0.015s > > `ls /cygdrive/c` or `ls /cygdrive/d` take around 0.013s. Is it possible there's another -- unavailable -- drive letter, and the driver needs to wait 4 seconds before declaring it unavailable/disconnected? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Why does ldd not show cyg*.dll in its output?
On 29. 6. 2016 23:45, David Macek wrote:
> I can try watching them side by side in debuggers tomorrow, maybe I'll find
> something.
Yep, found something. TL;DR the issue is that Windows spins a thread in the
process before our DLLs are loaded. Detailed analysis below.
On my Win8.x, the ldd "debugger" receives these events:
1. CREATE_PROCESS_DEBUG_EVENT
2. LOAD_DLL_DEBUG_EVENT for ntdll.dll
3. LOAD_DLL_DEBUG_EVENT for KERNEL32.DLL
4. LOAD_DLL_DEBUG_EVENT for KERNELBASE.dll
5. LOAD_DLL_DEBUG_EVENT for msys-intl-8.dll
6. LOAD_DLL_DEBUG_EVENT for msys-2.0.dll
7. LOAD_DLL_DEBUG_EVENT for msys-iconv-2.dll
8. EXCEPTION_DEBUG_EVENT ev.u.Exception = {ExceptionRecord = {ExceptionCode =
2147483651, ExceptionFlags = 0, ExceptionRecord = 0x0, ExceptionAddress =
0x7ffda38d1b90 , NumberParameters = 1,
ExceptionInformation = {0 }}, dwFirstChance = 1}
9. OUTPUT_DEBUG_STRING_EVENT ev.u.DebugString = {lpDebugStringData = 0x23f2a0
, fUnicode = 0,
nDebugStringLength = 24}
10. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread = {hThread = 0x88,
lpThreadLocalBase = 0x7ff5b000, lpStartAddress = 0x180044cf0
}
11. EXIT_THREAD_DEBUG_EVENT
12. EXIT_PROCESS_DEBUG_EVENT
I would say events #8 and #9 are not important (ldd ignores them as well).
Event #10 causes ldd to call `TerminateProcess` because we don't want any of
the analyzed program's code to run. This in turn causes events #11 and #12,
after which ldd exits.
On my Win10, events are like this:
1. CREATE_PROCESS_DEBUG_EVENT
2. LOAD_DLL_DEBUG_EVENT for ntdll.dll
3. LOAD_DLL_DEBUG_EVENT for KERNEL32.DLL
4. LOAD_DLL_DEBUG_EVENT for KERNELBASE.dll
(5) LOAD_DLL_DEBUG_EVENT for msys-intl-8.dll
6. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread = {hThread = 0x168,
lpThreadLocalBase = 0x22c000, lpStartAddress = 0x7fff19e80720
}
7. EXIT_THREAD_DEBUG_EVENT
8. EXIT_PROCESS_DEBUG_EVENT
Event #6 is the culprit here. NT apparently starts a thread in our process
which confuses ldd into believing that the process has finished loading DLL
from its import table and kills it, as explained above. The thread appears
non-deterministically, too, sometimes I see event #5 (and the associated DLL in
ldd's output), sometimes not. The thread's entry point is always the same and
ProcExp reports the same location (I checked in case of some symbol mash-up, as
it often happens when debugging across the Cygwin-Windows boundary). When I
broke ldd at `case CREATE_THREAD_DEBUG_EVENT`, the new thread's stack trace
(from ProcExp) looked like this:
ntoskrnl.exe!KeSynchronizeExecution+0x3f26
ntoskrnl.exe!KeWaitForMultipleObjects+0x10b5
ntoskrnl.exe!KeWaitForMultipleObjects+0xb6f
ntoskrnl.exe!KeWaitForSingleObject+0x370
ntoskrnl.exe!CmUnRegisterCallback+0x1b02c
ntoskrnl.exe!CmUnRegisterCallback+0x1c225
ntoskrnl.exe!NtVdmControl+0x45822
ntoskrnl.exe!FsRtlFreeExtraCreateParameter+0x44b
ntoskrnl.exe!KeSynchronizeExecution+0x4716
ntoskrnl.exe!KeSynchronizeExecution+0x4690
!RtlUserThreadStart
I came up with this naive fix:
--- ldd.cc.orig 2016-04-28 21:54:57.556500700 +0200
+++ ldd.cc 2016-06-30 22:18:05.332452300 +0200
@@ -357,6 +357,9 @@
}
break;
case CREATE_THREAD_DEBUG_EVENT:
+ if (ev.u.CreateThread.lpStartAddress == (void*)0x7fff19e80720) {
+break;
+ }
TerminateProcess (hProcess, 0);
break;
case EXIT_PROCESS_DEBUG_EVENT:
After which the output switched back to normal. One observed sequence of events:
1. CREATE_PROCESS_DEBUG_EVENT
2. LOAD_DLL_DEBUG_EVENT for ntdll.dll
3. LOAD_DLL_DEBUG_EVENT for KERNEL32.DLL
4. LOAD_DLL_DEBUG_EVENT for KERNELBASE.dll
5. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread = {hThread = 0x14c,
lpThreadLocalBase = 0x26a000, lpStartAddress = 0x7fff19e80720
}
6. LOAD_DLL_DEBUG_EVENT for msys-intl-8.dll
7. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread = {hThread = 0x138,
lpThreadLocalBase = 0x26c000, lpStartAddress = 0x7fff19e80720
}
8. LOAD_DLL_DEBUG_EVENT for msys-2.0.dll
9. LOAD_DLL_DEBUG_EVENT for msys-iconv-2.dll
10. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread = {hThread = 0x18c,
lpThreadLocalBase = 0x274000, lpStartAddress = 0x7fff19e80720
}
11. EXCEPTION_DEBUG_EVENT ev.u.Exception = {ExceptionRecord = {ExceptionCode =
2147483651, ExceptionFlags = 0, ExceptionRecord = 0x0, ExceptionAddress =
0x7fff19f2fd00 , NumberParameters = 1,
ExceptionInformation = {0 }}, dwFirstChance = 1}
12. OUTPUT_DEBUG_STRING_EVENT ev.u.DebugString = {lpDebugStringData = 0x5ff1a0
, fUnicode = 0,
nDebugStringLength = 24}
13. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread = {hThread = 0x118,
lpThreadLocalBase = 0x276000, lpStartAddress = 0x180044cf0
}
14. EXIT_THREAD_DEBUG_EVENT
15. EXIT_THREAD_DEBUG_EVENT
16. EXIT_THREAD_DEBUG_EVENT
17. EXIT_THREAD_DEBUG_EVENT
18. EXIT_PROCESS_DEBUG_EVENT
Here are some more stacktraces from various points in life of the cuckoo
threads, in case they are significant:
ntoskrnl.
Re: Why does ldd not show cyg*.dll in its output?
On 20. 5. 2016 3:20, Warren Young wrote: > On May 19, 2016, at 5:21 PM, Hans-Bernhard Bröker > wrote: >> >> Does not WFM: > > [snip] > >> This is with ldd.exe from cygwin-2.5.1-1, on Win10 64bit, installed into >> c:\cygwin64 Just bumped into this as well. Win10 64bit (1607 build 14367) with MSYS2 64bit: $ ldd /usr/bin/ls ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fff19e6) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fff198a) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fff1724) Win8.x 64bit with MSYS2 64bit: $ ldd /usr/bin/ls ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ffda381) KERNEL32.DLL => /c/Windows/system32/KERNEL32.DLL (0x7ffda331) KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7ffda0d8) msys-intl-8.dll => /usr/bin/msys-intl-8.dll (0x430b3) msys-2.0.dll => /usr/bin/msys-2.0.dll (0x18004) msys-iconv-2.dll => /usr/bin/msys-iconv-2.dll (0x3ff76) Both installations are up to date and should have identical binaries. Looking into procmon, the only relevant difference I see is `sysmain.sdb` being checked right after `ls.exe` process creation, but that could very well be a red herring. Unfortunately, ACT seems to be broken on Win10. I can try watching them side by side in debuggers tomorrow, maybe I'll find something. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: ldd differences
Sorry to hijack an old thread, but I think maybe the problem is not with ldd not understanding the binary, but with 64-bit libraries being mixed in (due to the WOW64 redirection not being enabled in some place). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Program start blocked / mintty?
On 22. 4. 2016 14:12, Thomas Wolff wrote: > If there is nothing cygwin can do, how could Avast be convinced to rectify > this issue? I have not used Avast for some time now (mostly due to its other bugs), but you can definitely add an exception for everything under cygwin/bin. I'm not sure if the sandboxing feature respects these exceptions, but you can always disable it completely. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: native Linux userland in Windows 10
On 21. 4. 2016 18:01, John Cowan wrote: > David Macek scripsit: > >> You're assuming LSW will become pre-installed on these workstations and >> UoW will become a Windows Store "app". I'm not saying it can't happen, >> but it seems unlikely at the moment. > > Why unlikely? That is exactly what is the case, if you are running > the current alpha build of Windows 10. Build #14316? You have to switch to developer mode, then install the subsystem which is a "Windows feature". Both require administrator privileges IIRC. Then you can run `bash` or `lxrun /install` to download the Ubuntu tarball, allegedly from the Store. Until I can go to the Store app on a clean Windows install, write "Ubuntu" and click on Install, I won't consider UoW as "available through the Windows Store" as Warren Young wrote. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: native Linux userland in Windows 10
Note that I'm not necessarily arguing against you in every point you wrote. Some reactions are just notes. On 21. 4. 2016 0:10, Warren Young wrote: > One such example is the recent complaint thread about Git’s path handling, > which wouldn’t even come up under UfW, because it isn’t Windows at all. Git > under UfW has exactly the same semantics as under Linux, where presumably the > semantics are perfect, since Linux is git’s natural environment. > > Another example is CRLF and UTF-8 handling. Any program running under Cygwin > that bypasses its POSIX interfaces (e.g. calling ReadFile() instead of > read(2)) will likely do strange things with LF-terminated UTF-8 text files, > whereas a UfW binary will always assume LF and UTF-8 (or $LANG, anyway) text > encoding. Thus, all the hacks in Cygwin and Cygwin-ported executables for > CRLF workarounds (e.g. Cygwin’s “text” mount option hack, the crnl-glob > feature in Fossil to make it ignore CRs when determining if a file is > “binary”, etc.) don’t need to exist under UfW. > > Still another example is the unfortunate mismatches in Windows vs POSIX file > locking semantics, as you recently noted in your recent thread complaining > about another “useless” feature, Cygwin’s flock() implementation. Again, the > insides of the UfW box are completely POSIX, not Windows at all, so > presumably locking semantics are Linux-native (i.e. advisory by default, > rather than mandatory), too, so there is no mismatch between Windows and > POSIX semantics. Here, the wall between NT subsystems helps: you can’t have a > Windows app and a UfW app fighting for lock control of a single file, since > Windows apps can’t even see inside the UfW filesystem. So far you're enumerating limitations of Cygwin-Win32 interoperability, not limitations of Cygwin. Correct me if I'm wrong, but AFAIK if you stick to (well-written) Cygwin programs and Cygwin filesystem, you don't have to work around wrong line endings nor strong locks. > (You could have such a fight through the /mnt/[driveletter] door, but that’s > like arguing that the availability of NFS or SMB locking prevents Linux > locking semantics from working correctly. Conflicts can only occur in the > shared filesystem.) I would like to make the same argument for Cygwin and /cygdrive. > 4. You’re using Cygwin on Windows to test software that normally builds and > runs on Linux on a PC where installing Linux or a VM manager isn’t an option. > (e.g. A typical corporate locked-down desktop PC.) Given a choice between > Cygwin and UfW, both will work You can install UoW without admin privileges? Or from another POV, you can install UoW but not VirtualBox? > In fact, in such an environment, UfW might have a distinct advantage, being > available through the Windows Store. A typical corporate PC lock-down policy > might not restrict installation from the Windows Store (such apps being > pre-vetted, signed, and therefore “safe”) but might prevent installation of > Cygwin, since Cygwin is third-party and doesn’t normally install on a > per-user basis. You're assuming LSW will become pre-installed on these workstations and UoW will become a Windows Store "app". I'm not saying it can't happen, but it seems unlikely at the moment. > (Indeed, iperf3 doesn’t build OOTB on Cygwin due to an API conflict with > newlib, a problem that doesn’t impact glibc based systems like UfW.) Although practically speaking, Linux is more comfortable because people primarily target Linux, it'd be better to push for programs to be truly POSIX-portable instead of furthering the Linux near-monopoly. > 6. A lot of Unix software runs like a pig under Cygwin due to the user-space > gyrations Cygwin must go through to implement POSIX semantics under Windows. Midipix could end up taking the place of the top competitor of LSW/UoW performance-wise, while retaining interoperability with Win32. > 8. All of us who greatly prefer installing software via a command line > package manager (e.g. apt, pkg, brew, yum…) rather than a GUI (e.g. > setup.exe) will probably be happier under UfW than on Cygwin. This is fixable. MSYS2 already has pacman which can do the same. (Thanks to Cygwin developers, among others.) > 9. A lot of software for Linux simply isn’t portable enough to build under > Cygwin, and there is no native Windows port. Such software may do low-level > unportable things, include assembly language hacks, etc. that don’t work on > Windows, so your only alternative heretofore to run such software on a > Windows box was to run a Linux VM. (e.g. Node.js, the Oracle JVM (as opposed > to Cygwin’s current JVM alternative, gcc-gcj), Valgrind, etc.) This is definitely a win for LSW/UoW, because it goes for Linux compatibility. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Trunk of 'file' fails to build due to regex error
On 10. 2. 2016 12:58, Corinna Vinschen wrote: > I replied in the bug tracker. It seems a fix (or at least a work-around) was implemented based on your replies. I can now build `file` from trunk without any issues. Thanks. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Trunk of 'file' fails to build due to regex error
Hi all.
I'm trying to build the `file` program from trunk, but I'm getting a regex
error that seems to be related to 8-bit character handling in Cygwin.
The error happens when compiling the magicfile:
> file: line 83: regex error 17 for `[=.<>|!^▒]{79}', (illegal byte sequence)
I currently have little idea where to start in investigating this error. I'd be
glad if someone could help.
See <http://bugs.gw.com/view.php?id=518> for upstream bug where there's a link
to <https://cygwin.com/ml/cygwin/2013-07/msg00426.html> which seems to be about
a very similar (if not the same) error, but more than 2 years ago.
--
David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
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
Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
On 3. 12. 2015 0:00, Corinna Vinschen wrote: > On Dec 2 16:43, René Berber wrote: >> I don't know were you can see the specific Windows version, but AFAIK it >> hasn't been updated recently (the System Info only shows "Windows 10 >> Pro", 64-bit). > > That's oh so funny: The good old system info doesn't show this anymore. > But you can look into the new-style "Settings" -> System -> About. I've always used the trusty `winver` for version info. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
On 1. 12. 2015 18:40, David Macek wrote: > On 1. 12. 2015 15:01, Corinna Vinschen wrote: >> On Dec 1 21:07, nu774 wrote: >>>> There must be a bug in the new CMD somewhere. But, anyway, I'll look >>>> into it when I finally managed to update my W10 test machine. >>> >>> No, cmd.exe is just an example. Any 32bit process can be an trigger. >>> I guess something has changed in TH2 kernel regarding process memory >>> management or something that interferes cygwin's fork(). >> >> If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then >> there's some foul-up in the WOW64 layer in terms of starting 64 bit >> processes, perhaps. Sigh, it's a rather unexpected change after it >> worked fine for so long :( > > Yup. I can confirm. Just for the record, we did some debugging over IRC and it seems it's an issue with WOW64 where the stack in the first 64-bit process is offset for some reason. Citing Corinna: "I wonder if we have to resurrect the old wow64_respawn_process function for this border case" -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
On 1. 12. 2015 15:01, Corinna Vinschen wrote: > On Dec 1 21:07, nu774 wrote: >>> There must be a bug in the new CMD somewhere. But, anyway, I'll look >>> into it when I finally managed to update my W10 test machine. >> >> No, cmd.exe is just an example. Any 32bit process can be an trigger. >> I guess something has changed in TH2 kernel regarding process memory >> management or something that interferes cygwin's fork(). > > If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then > there's some foul-up in the WOW64 layer in terms of starting 64 bit > processes, perhaps. Sigh, it's a rather unexpected change after it > worked fine for so long :( Yup. I can confirm. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On 26. 11. 2015 12:53, Corinna Vinschen wrote: > On Nov 24 20:51, David Macek wrote: >> My test command is `touch 1 && ln -s 1 2`, then I clean up by `rm 1 2`. Now >> the results: >> >> in /bin/: relative >> in /: absolute >> in ~/ (/cygdrive/c/Users/username/): relative >> in /cygdrive/w/: absolute >> >> Note that W: is a permasubst (created using `DOSDevices` in registry), which >> would explain the different behaviour (but not excuse it :), but I don't see >> why / is also special. Even if only one from the link pair (target or >> source) is in a relative-symlink-unsupporting path, I get an absolute path. >> >> Can you confirm? > > Yes, thanks for this part of the analysis. There was a typo in the > code checking the relative paths. The check for a drive colon in the > pathname used a wrong offset into the path string, which ultimately > always created an absolut path to the target if the path of the > target was in a drive's root dir or one level below that. > > I fixed that in the repo and created a new developer snapshot for > testing: https://cygwin.com/snapshots/ Please give it a try. I get relative symlinks in all of my test cases now. Thanks. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: mksnt sh is invoked when executing cygwin icon;
On 26. 11. 2015 2:27, Kenneth Wolcott wrote: > Hi; > > It seems that a 32bit Windows server with a pre-existing MKS Toolkit > installation prevents an interactive Cygwin window (mintty) from > starting properly. > > If the c:\mksnt directory (where MKS Tookkit is installed) is > renamed to c:\NOTmksnt, then double-clicking the Cygwin icon results > in: > > "Failed to run C:/mksnt/sh.exe: No such file or directory" > > But if the c:\NOTmksnt directory is renamed back to what it was, then > the window opens up with sh.exe from mksnt instead of bash and seems > to hang for a very long time. > >Why is this? Part of me thinks that Cygwin and MKS Toolkit should > just coexist just fine, each not knowing about the other (c:\cygwin > and c:\mksnt). Part of me thinks that I'd like to have Cygwin come > first in the path rather than having c:\mksnt first in the path. Is > there a way to force the Cygwin install process (or fix it afterward) > to put Cygwin first? > > I tried to change /etc/profile so that the PATH variable was set to > exclusively Cygwin stuff, but that had no effect. > > How to fix this outside Cygwin? (The Windows side) > > How to fix this inside Cygwin? Sounds to me like your login shell is hard-coded to C:/mksnt/sh.exe. What does `getent passwd $(whoami) | cut -d: -f7` say (run `C:\cygwin\bin\bash --login -i` directly to get a working shell)? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
Can you describe what purpose does your C:\proc serve? I'm not currently arguing for or against Corinna's proposal, I'm just curious. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On 20. 11. 2015 10:26, Corinna Vinschen wrote: > On Nov 19 22:17, David Macek wrote: >> On 19. 11. 2015 20:36, Nellis, Kenneth wrote: >>> FWIW, my results are different: >>> >>> $ printenv CYGWIN >>> winsymlinks:nativestrict >>> $ touch XXX >>> $ ln -s XXX YYY >>> $ ln -s YYY ZZZ >>> $ ls -l >>> total 0 >>> -rw-r- 1 knellis Domain Users 0 Nov 19 14:28 XXX >>> lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 YYY -> XXX >>> lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 ZZZ -> YYY >>> $ uname -svr >>> CYGWIN_NT-6.1 2.3.1(0.291/5/3) 2015-11-14 12:44 >>> $ >> >> Weird. I also tried in the virtual root directory, in case cygdrive affects >> it, but no luck, still absolute paths. >> >> I'm on Windows 10, if it makes any difference. > > No, I'm on W10 either and it works for me as for Kenneth. The path > evaluation in the function creating native symlinks tries to create > relative Windows paths if the incoming target path is relative, too. > Basically it compares the path prefixes, eliminates as much of > the path as possible and prepends "..\\" as required. > > I don't see a reason why this shouldn't work for you, unless the > shell mangles the paths before passing them to the ln command (yes, > this really may happen with some shells depending on settings) It seems it's dependent on the directory after all. The shell doesn't seem to affect it, at least not in my tests. My test command is `touch 1 && ln -s 1 2`, then I clean up by `rm 1 2`. Now the results: in /bin/: relative in /: absolute in ~/ (/cygdrive/c/Users/username/): relative in /cygdrive/w/: absolute Note that W: is a permasubst (created using `DOSDevices` in registry), which would explain the different behaviour (but not excuse it :), but I don't see why / is also special. Even if only one from the link pair (target or source) is in a relative-symlink-unsupporting path, I get an absolute path. Can you confirm? Output of `mount`: D:/cygwin64/bin on /usr/bin type ntfs (binary,auto) D:/cygwin64/lib on /usr/lib type ntfs (binary,auto) D:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) J: on /cygdrive/j type ntfs (binary,posix=0,user,noumount,auto) W: on /cygdrive/w type ntfs (binary,posix=0,user,noumount,auto) -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On 20. 11. 2015 10:29, Corinna Vinschen wrote: > On Nov 19 19:53, David Macek wrote: >> On 18. 11. 2015 20:48, Corinna Vinschen wrote: >>> On Nov 18 19:13, David Macek wrote: >>>> On 18. 11. 2015 18:55, Corinna Vinschen wrote: >>>>> On Nov 17 23:28, David Macek wrote: >>>>>> I went through the UG looking for differences between regular Cygwin >>>>>> symlinks and NTFS symlinks, but couldn't find this documented. It >>>>>> seems that when using winsymlinks:native, the target path is first >>>>>> dereferenced before storing it in the link. >>>>> >>>>> It's a result of the native symlink being a Windows path. The >>>>> ultimate conversion from POSIX to Windows path dereferences all >>>>> symlinks. >> >> Hmm. I just performed a test on my Cygwin installation and it doesn't >> seem to match the described behavior. > > Symlinks within the path, e.g : /home/foo/symlink/bar/baz > > If the above symlink is not a native symlink, the above path > converted to Windows notation > > C:\cygwin64\home\foo\symlink\bar\baz > > is invalid. Ah. Now I understand. Thanks. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Install Cygwin on mounted drive for multiple concurrent users on multiple machines?
On 19. 11. 2015 23:52, Kenneth Wolcott wrote: > Hi; > > I didn't see this in the Cygwin FAQ (perhaps I didn't look carefully > enough or perhaps it is too obvious a question). > > Instead of installing Cygwin on each Windows machine, is it > advisable to install it once on a public mounted drive? Then not only > multiple users (concurrent or not) could use Cygwin on multiple > machines (concurrently or not) from one place. Since many of the > machines I want to install Cygwin are short of disk space on the local > drive, but there seems to be sufficient space for a slightly larger > than minimal Cygwin installation on a public drive, is this advisable? > I guess I'd see a performance hit if Cygwin were not installed on a > local drive. Are there any other concerns? Potential concerns: - location of home directories (same as Windows, or in $cygwinroot/home, or somewhere else) - location of tmp (one shared in $cygwinroot/home, or per-user, or something else) - location of var, for example for apps that put pidfiles there (one shared, per-user, else) Essentially, as with any other shared app with possibly concurrent use, the program directory should ideally be read-only and any user-generated state gets written in per-user directories. I'm also suspicious of whether advanced filesystem features will work on a network path, e.g. deleting/updating files/binaries when in use. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On 19. 11. 2015 20:36, Nellis, Kenneth wrote: > FWIW, my results are different: > > $ printenv CYGWIN > winsymlinks:nativestrict > $ touch XXX > $ ln -s XXX YYY > $ ln -s YYY ZZZ > $ ls -l > total 0 > -rw-r- 1 knellis Domain Users 0 Nov 19 14:28 XXX > lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 YYY -> XXX > lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 ZZZ -> YYY > $ uname -svr > CYGWIN_NT-6.1 2.3.1(0.291/5/3) 2015-11-14 12:44 > $ Weird. I also tried in the virtual root directory, in case cygdrive affects it, but no luck, still absolute paths. I'm on Windows 10, if it makes any difference. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On 18. 11. 2015 20:48, Corinna Vinschen wrote: > On Nov 18 19:13, David Macek wrote: >> On 18. 11. 2015 18:55, Corinna Vinschen wrote: >>> On Nov 17 23:28, David Macek wrote: >>>> I went through the UG looking for differences between regular Cygwin >>>> symlinks and NTFS symlinks, but couldn't find this documented. It >>>> seems that when using winsymlinks:native, the target path is first >>>> dereferenced before storing it in the link. >>> >>> It's a result of the native symlink being a Windows path. The >>> ultimate conversion from POSIX to Windows path dereferences all >>> symlinks. Hmm. I just performed a test on my Cygwin installation and it doesn't seem to match the described behavior. /cygdrive/w/temp $ export CYGWIN=winsymlinks:nativestrict /cygdrive/w/temp $ touch XXX /cygdrive/w/temp $ ln -s XXX YYY /cygdrive/w/temp $ ln -s YYY ZZZ /cygdrive/w/temp $ ls -l ... -rwxrwxr--+ ... XXX lrwxrwxrwx ... YYY -> /cygdrive/w/temp/XXX lrwxrwxrwx ... ZZZ -> /cygdrive/w/temp/YYY What's interesting though, is that the paths are converted to absolute ones. This again only happens for winsymlinks:native, but NTFS symlinks have no such restriction and `mklink` happily creates relative links. >> Should that behaviour stay? > > Yes. Consider that neither Cygwin or Interix symlinks with SYSTEM bit > set, nor symlinks using WIndows shortcuts make any sense as part of a > native symlink. As a result, Cygwin does a full path conversion from > POSIX to symlink-less Windows path to crate native symlinks. I'm sorry, but I'm not sure I understand. What does "to be as part of a symlink" mean in this context and how did non-NTFS symlinks get into the discussion? *** After thinking about this for some time, I began to assume that "part of a symlink" was meant as "a symlink target". In that case, it seems that Cygwin is pretty intelligent about this, as the dereferencing only happens when targetting a non-NTFS symlink, at least in trivial cases. If that's the case, then I'm okay with that (and I'll try to document it), and the only question that remains is the one about relative paths (see above). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Symlink targets dereferenced when winsymlinks:native
On 18. 11. 2015 18:55, Corinna Vinschen wrote: > On Nov 17 23:28, David Macek wrote: >> Hi. >> >> I went through the UG looking for differences between regular Cygwin >> symlinks and NTFS symlinks, but couldn't find this documented. It >> seems that when using winsymlinks:native, the target path is first >> dereferenced before storing it in the link. > > It's a result of the native symlink being a Windows path. The > ultimate conversion from POSIX to Windows path dereferences all > symlinks. Should that behaviour stay? If not, I can send a patch for the UG. >> That doesn't happed when >> using regular symlink files. Is this behaviour intentional / known? >> >> If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. > > It matters. This is a bug in Cygwin, a missing test in fact. It should > never allow to create native symlinks to targets which only exist inside > of Cygwin. Consider that /proc/self/fd has no meaning to non-Cygwin > processes at all. Creating this symlink as native symlink doesn't make > any sense, they should always be generated as Cygwin-only symlinks. > > Thanks for the report, I'll apply a matching patch. Cool. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Symlink targets dereferenced when winsymlinks:native
Hi. I went through the UG looking for differences between regular Cygwin symlinks and NTFS symlinks, but couldn't find this documented. It seems that when using winsymlinks:native, the target path is first dereferenced before storing it in the link. That doesn't happed when using regular symlink files. Is this behaviour intentional / known? If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Recent change to terminal icon / mintty breaks taskbar pinning
On 11. 11. 2015 15:33, cyg Simple wrote: > On 11/11/2015 7:12 AM, Corinna Vinschen wrote: >> On Nov 11 10:32, Adam Dinwoodie wrote: >>> On Wed, Nov 11, 2015 at 09:53:29AM +0100, Corinna Vinschen wrote: >>>> On Nov 11 06:53, Andrey Repin wrote: >>>>> 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. >>>> >>>> Yeah, pinning is only controlled by Windows itself (shell32 >>>> functionality, probably). It's not under the control of the >>>> application the shortcut points to. >>> >>> Not so. This is related to the recent MinTTY changes[0]. I get the >>> bugged behaviour on v2.2.1-0, but if I downgrade to v2.1.5-0, I get the >>> behaviour Brian is describing as correct, with the command line >>> arguments preserved when the program is pinned. >>> >>> I'll guess this is, in particular, related to the "optional Windows >>> taskbar integration" listed in the changelog in the announcement email. >> >> Oh, ok, I didn't know that. Thanks for clarifying. > > Yes indeed thanks for clarifying. The issue exists regardless of if you > pin the running task or you pin the Desktop icon. Pinning the Desktop > icon will cause a new icon on the taskbar when MinTTY is executing. > Pinning the open task will cause subsequent task to bypass initial > startup and be sitting in /usr/bin instead of $HOME. Pinning the open task and then modifying the pinned shortcut to include the correct arguments should make it work (both grouping and environment in shell). Anyway, mintty has reverted the change, so v2.2.2 will probably work just like the ones before v2.2.1, once released. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Non-Cygwin slaves inside tmux
On 27. 5. 2015 12:04, Robert Pendell wrote: > while we wait for someone that does to see if the > issue is reproducible for them can you please *attach* a cygcheck.out > for your system Attached. > and also check your system for BLODA just in case? Disabling Windows Defender had no effect. -- David Macek Cygwin Configuration Diagnostics Current System Time: Fri Jun 05 00:06:23 2015 Windows 8.1 Professional Ver 6.3 Build 9600 Path: D:\cygwin64\usr\local\bin D:\cygwin64\bin C:\Windows\System32 C:\Windows Output from D:\cygwin64\bin\id.exe UID: 197609(ether) GID: 197121(None) 197121(None) 197612(Debugger Users) 197613(HelpLibraryUpdaters)578(Hyper-V Administrators) 559(Performance Log Users) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users)15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication) 401408(Medium Mandatory Level) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'ether' PWD = '/cygdrive/c/Users/ether' HOME = '/cygdrive/c/Users/ether' USERDOMAIN_ROAMINGPROFILE = 'onyx' HOMEPATH = '\Users\ether' APPDATA = 'C:\Users\ether\AppData\Roaming' ProgramW6432 = 'C:\Program Files' PACKAGER = 'David Macek ' HOSTNAME = 'onyx' SHELL = '/bin/bash' TERM = 'xterm' _NT_SYMBOL_PATH = 'symsrv*symsrv.dll*C:\temporary\symbols*http://msdl.microsoft.com/download/symbols' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 58 Stepping 9, GenuineIntel' PROFILEREAD = 'true' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/Users/ether' ORIGINAL_PATH = '/cygdrive/c/Windows/System32:/cygdrive/c/Windows' USERDOMAIN = 'onyx' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' ANSICON_DEF = '7' PYTHONIOENCODING = 'UTF-8 ' !:: = '::\' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'ether' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' ChocolateyInstall = 'C:\temporary\chocolatey' FONTCONFIG_PATH = 'C:\Users\ether\AppData\Roaming\fontconfig' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\PowerShell\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' EDITOR = 'mc -e' VS120COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\' USERPROFILE = 'C:\Users\ether' LANG = 'en_US.UTF-8' TZ = 'Europe/Prague' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\ONYX' PYTHONDONTWRITEBYTECODE = 'True' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'AMD64' LOCALAPPDATA = 'C:\Users\ether\AppData\Local' !C: = 'C:\Users\ether' ProgramData = 'C:\ProgramData' EXECIGNORE = '*.dll' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' [redacted] _NT_SYMCACHE_PATH = 'C:\temporary\symbols\_cache' PROMPT = '$E[1m$P$G$E[0m ' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\Windows' PRINTER = [redacted] PROCESSOR_REVISION = '3a09' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info' UNISONBACKUPDIR = 'W:\backups\unison' PROGRAMFILES = 'C:\Program Files' VS110COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\' NUMBER_OF_PROCESSORS = '4' asl.log = 'Destination=file' SESSIONNAME = 'Console' LC_TIME = 'C.UTF-8' COMPUTERNAME = 'ONYX' !ExitCode = '' ANSICON = '150x (150x42)' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\W:\[redacted]' f76db13c759b51fa = '\??\D:\cygwin64' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\TortoiseGit\History\RemoteBranch\W_\temporary\development\cygwin (default) = 'develop' HKEY_CURRENT_USER\Software\TortoiseGit\TortoiseProc\PullFetch\W_\dev\cygwin_0 (default) = 0x HKEY_CURRENT_USER\Software\TortoiseGit\TortoiseProc\Push\W_\dev\cygwin (default) = 0x0001 HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\D:\cygwin64' HKEY_LOC
Non-Cygwin slaves inside tmux
Hi. My testcase: run mintty-bash, run tmux inside and run netsh inside. Try to type. Result: horrible lags Expected result: it's possible to type normally I tried multiple Cygwin snapshots from the last 5 months, hoping that it could be a regression (therefore easily fixable), but all of them exhibit the same issue. A quick Google search didn't show any similar errors, so I'm reporting here in hope someone will be able to say "yeah, that's easy, let me fix that". :) Assuming I understand correctly the roles here -- bash does fork+exec(netsh) and Cygwin emulates that by creating a bash subprocess which creates a netsh subprocess; the bash process that is spawned to execute the native executable is creating threads and named pipes like crazy. Every few seconds a new pipe and thread pop up. All the old threads seem to be stuck in: #0 0x7ffad7f3120a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll #1 0x7ffad53b1118 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/KERNELBASE.dll #2 0x000180134cfb in muto::acquire (this=0x639363438, ms=ms@entry=4294967295) at /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/sync.cc:87 #3 0x0001800f9ed9 in lock_process (exiting=false, this=) at /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/sync.h:53 #4 commune_process (arg=0x6e7cb90) at /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/pinfo.cc:542 ... several other frames which are related to Cygwin threads, I assume ... strace shows tmux getting these: seterrno_from_win_error: /usr/src/ports/cygwin/cygwin-2.0.2-1.x86_64/src/newlib-cygwin/winsup/cygwin/pinfo.cc:737 windows error 995 -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Issue while running Visual Studio's devenv through ssh
On 15. 5. 2015 21:08, The General wrote: > Any feedback is much appreciated, and if anyone needs more information > please don't hesitate to ask. Is the error in any way tied to number of previous build invocations? Not that I have the slightest idea what the problem is, but have you tried comparing ProcMon traces of a successful and an unsuccessful build? Coming at it from another angle, maybe revert to the working snapshot, and get a ProcMon trace (possibly with a reasonably chosen filters and saving to a file instead of memory) of the interval between the working and broken states? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Cannot create a native symlink in not current directory
On 10. 5. 2015 23:27, Пётр Б. wrote: > ln -s x y > > Everything works. > > ln -s x ../y > >> ln: failed to create symbolic link ‘../y’: No such file or directory > > Now it is interesting. WHAT IS THIS. Am I not getting something? > > Same command works perfectly with non-native links. Maybe you already know, but it took me a while to realize, so I'll mention it here: `ln -s target ../link` executed in directory /foo/bar will create /foo/link targeting "target", i.e. /foo/target (and not /foo/bar/target as I thought). Cygwin refuses to create NTFS symlinks to non-existing targets. This is due to a mismatch between NTFS and POSIX symlink semantics. Given this information, the error you're seeing should now be obvious to you. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Deleting files with open handles on subst'd drives
On 23. 4. 2015 15:24, Corinna Vinschen wrote: > I hacked a bit on that and it seems the solution was easier than I thought. > I uploaded new developer snaphshots to https://cygwin.com/snapshots/ > Replacing the Cygwin DLL alone is sufficient for testing. Please give it > a try. I'm sorry for a late reply. The snapshot seems to fix the issue. Based on a quick read of your patch, I thought I could break it with a second-level subst (subst->subst->volume), but it worked even then. Thank you. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Deleting files with open handles on subst'd drives
On 23. 4. 2015 15:25, Nick Hansen wrote: > Unsubscribe Are you trying to unsubscribe from a thread, or from the whole mailing list? Please read: http://cygwin.com/ml/#unsubscribe-simple -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Deleting files with open handles on subst'd drives
Hello everyone.
Some time ago, I encountered a problem in a script when run on Cygwin/MSYS2. To
add some drama, I'll mention that the problem caused some data loss (nothing
important though). The problem is that some operations on open files seem to
fail on subst'd drives (but not on regular ones).
To reproduce the problem, choose some writable directory and run:
$ subst X: C:/somesubdir
$ cd /cygdrive/x/
$ touch foo
$ { rm foo; touch foo; } https://gist.github.com/elieux/6463521192baed613099>
I compared this with the same operations running on a regular drive, but I
couldn't find any difference in how `rm` deletes the file nor in how `touch`
creates the file. Just the result of the last NtCreateFile is different
(STATUS_SUCCESS vs. STATUS_DELETE_PENDING).
Thoughts?
--
David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Is it possible to display English phonetic alphabet in Mintty?
On 20. 4. 2015 15:18, Rexdf wrote: > I have a dictionary in cygwin. It cannot display the phonetic alphabet well. What are your LANG, LANGUAGE, LC_* variables? I see boxes when I set LANG="en_US", but not when I set LANG="en_US.UTF-8" or empty LANG. More info: <https://cygwin.com/cygwin-ug-net/setup-locale.html> -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Documentation on fstab out of date
On 18. 4. 2015 19:21, Steven Penny wrote: > On Sat, Apr 18, 2015 at 9:47 AM, David Macek wrote: >> According to has_exec_chars, the sniffing routine also looks for "MZ" (EXE/PE >> files) and ":\n" (batch files? (can anyone confirm this?)). > > Yeah, I can confirm that it does nothing. AFAIK `file` doesn't consult this routine in any way. Try this instead: $ mount "$(cygpath -m "$TMP")" /home -o noacl $ cd /home $ touch alpha.sh bravo.sh charlie.bat delta.bat $ echo '#!/bin/sh' > bravo.sh $ echo : > delta.bat $ ls -l -rw-r--r-- 1 me None0 Apr 18 20:53 alpha.sh -rwxr-xr-x 1 me None 10 Apr 18 20:53 bravo.sh -rw-r--r-- 1 me None0 Apr 18 20:53 charlie.bat -rwxr-xr-x 1 me None2 Apr 18 20:53 delta.bat -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Documentation on fstab out of date
Hi. It seems to me that <https://cygwin.com/cygwin-ug-net/using.html#mount-table> is out of sync with actual Cygwin behaviour in few aspects. What's the established process on updating these docs? List of issues I found follows. > Recognized options are binary, text, nouser, user, exec, notexec, cygexec, > nosuid, posix=[0|1]. The meaning of the options is as follows. There are more options, as can be seen below the cited paragraph. > Files ending in certain extensions (.exe, .com, .bat, .btm, .cmd) are assumed > to be executable. My reading of fhandler_disk_file.cc suggests it's only .exe, .com, and .lnk these days. Interestingly, nt_path_has_executable_suffix (only used in the rename syscall, AFAICT) looks for a different set of suffixes (.com, .dll, .exe, .scr, .sys). > Files whose first two characters begin with '#!' are also considered to be > executable. According to has_exec_chars, the sniffing routine also looks for "MZ" (EXE/PE files) and ":\n" (batch files? (can anyone confirm this?)). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: [TESTERS needed] New POSIX permission handling
On 11. 4. 2015 11:59, Corinna Vinschen wrote: >> Out of curiosity, does the code somehow distinguish ACLs that don't >> have these default permissions (or have different permissions set for >> SYSTEM / Administrators)? > > I don't quite understand the question. > > For a start, I'd like to point out how POSIX ACLs are supposed to work. > http://linux.die.net/man/5/acl is a good start. This is our role model. I'm gonna read that. > The new code will compute the mask the same way as before, but it > skips the permissions of SYSTEM and Administrators while doing that. > That means, the POSIX group permission bits are not affected by > the Windows-typical permissions of SYSTEM and Administrators. > > Example: > > Userrw- > Primary group r-- > Other user rw- > Other group r-- > SYSTEM rwx > Everyone--- > > The computed POSIX MASK/CLASS_OBJ value in Cygwin 1.7.35 is the sum > of all group and secondary user permissions > > rw- | r-- | rwx == rwx > > The new code ignores SYSTEM, thus the mask is > > rw- | r-- == rw- > > Does this explain it sufficiently? Yes, thank you. My question was about the case where SYSTEM or Administrator doesn't have the typical permissions. From this explanation, I assume that I won't be able to see any difference in the mask in that case, but it doesn't seem to be a bad thing. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: [TESTERS needed] New POSIX permission handling
On 11. 4. 2015 11:08, Achim Gratz wrote: > David Macek writes: >> Power Users don't have access to (almost) everything, like >> Administrators do. The Domain Administrators group is a member of >> Administrators, so unless I'm missing something, there's no reason to >> have them explicitely in the DACL. > > That doesn't stop folks from using them in DACL entries and membership > of one group in another (rightly) doesn't confer transitive access > rights. I've just named these two examples because I've seen them > before in ACL, I make no claim as to whether that's a sensible thing to > do or not. https://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx says otherwise about the group-in-group rights. I'm a bit confused. Maybe we're talking about different things -- of course it makes sense to give Domain Administrators more rights than Administrators, but I don't see any reason for blanket granting Domain Administrators explicit rights on everything on the filesystem. The way I see it, the point of the code change was to prevent the "implicit" Administrators and SYSTEM DACL entries from showing up in the computed POSIX access mask because they nicely match the implicit rights root accounts have on POSIX systems and because they're unhelpful and sometimes problematic. As neither Domain Administrators nor Power Users have this combination of properties (presence on most filesystem objects by default and SeTakeOwnershipPrivilege), I think it's useful to have them appear in the mask. Please correct me if I'm talking nonsense; I have little practical experience with domain environments. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: [TESTERS needed] New POSIX permission handling
On 11. 4. 2015 10:47, Achim Gratz wrote: > Corinna Vinschen writes: >> - 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. Out of curiosity, does the code somehow distinguish ACLs that don't have these default permissions (or have different permissions set for SYSTEM / Administrators)? > Since you've now opened that can of worms of who is considered "root", > what about "Domain Administrators" or "Power Users", for starters? > >> That means, even if SYSTEM or Administrators have full access to the >> file, the POSIX permssion bits will not reflect that fact. And while >> other users get access denied based on the mask value, SYSTEM and >> Administrators will never get access denied based on the mask. > > If you want to put this to better use in larger settings it would seem > preferrable if it was possible to define a list of users to treat this > way in fstab. I think this would help with the braindead settings > NetApp filers are set up these days by default. That generally means > that some domain group(s) need to be considered root on the share > depending on which share you are accessing. Power Users don't have access to (almost) everything, like Administrators do. The Domain Administrators group is a member of Administrators, so unless I'm missing something, there's no reason to have them explicitely in the DACL. I'm not arguing against configurability though. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: 1.7.35: possible backspace key and arrow keys bug
On 9. 4. 2015 18:54, Weston Turner wrote: > I corroborate the original poster's experience with this issue. > > Steps to reproduce the issue: for example open a file with vim under > Cygwin, press: up, up, down, down, left, left, right, right. Vim under > Cygwin places: > > C > C > D > D > B > B > A > A > > in the file due to the arrow keys being pressed. Vim under bash on > Linux or the Mac terminal does not treat the arrow keys as file input, > but rather simply uses them to move the cursor about in the file. I thought this would be a widely known problem by now. :) Does setting `set nocp` in .vimrc help? (More possible solutions here: http://vim.wikia.com/wiki/Fix_arrow_keys_that_display_A_B_C_D_on_remote_shell) -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: setfacl can kill a drive
On 8. 4. 2015 12:17, Steven Penny wrote: > Also I discovered this > > $ setfacl -b /cygdrive/c > > After that you get this > > C:\ is not accessible. > Access is denied. > > Luckily this was in a virtual machine. Otherwise, can this be undone? This is > very dangerous, and I feel it should be protected similarly to > "rm --no-preserve-root" The root of the C drive should be easy to fix, as most of the directories there don't inherit its permissions. You should be able to use Windows Explorer to fix the permissions, but maybe takeown and icacls will be more precise tools for this task. This is the ACL for my C root: C:\> icacls . . NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) NT AUTHORITY\Authenticated Users:(OI)(CI)(RX) BUILTIN\Users:(OI)(CI)(RX) Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW) -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: Process under strace hangs sometimes
Hi all. During an attempt to solve some (unrelated) issues, I noticed that running a configure script under strace would cause it to hang indefinitely (or at least for a very long time). I managed to reduce the script to one line; you should be able to reproduce with the following two commands. echo 'echo $1 `(set -o) > /dev/null`' > hanger for i in $(seq 1000); do strace -o ./log sh ./hanger $i; done Unfortunately, it seems that the simpler the script is, the rarer the hang is. I need around 30 invocations, but when I asked other people to reproduce, they reported even larger numbers. I hope I included everything important. If not, I'll be happy to provide more information. -- David Macek Cygwin Configuration Diagnostics Current System Time: Sun Mar 29 23:59:58 2015 Windows 8.1 Professional Ver 6.3 Build 9600 Path: D:\cygwin64\usr\local\bin D:\cygwin64\bin C:\Program Files (x86)\PC Connectivity Solution C:\ProgramData\Oracle\Java\javapath C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files (x86)\Intel\iCLS Client C:\Program Files\Intel\iCLS Client C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files\Intel\Intel(R) Management Engine Components\DAL C:\Program Files\Intel\Intel(R) Management Engine Components\IPT C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT C:\Program Files (x86)\GTK2-Runtime\bin C:\Program Files\TortoiseHg C:\Program Files\TortoiseSVN\bin C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit C:\Program Files\Microsoft SQL Server\110\Tools\Binn C:\Program Files\Microsoft\Web Platform Installer C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0 C:\Program Files\Microsoft SQL Server\120\Tools\Binn C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn C:\Program Files\Microsoft SQL Server\120\DTS\Binn C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn C:\Program Files\TortoiseGit\bin W:\[redacted] W:\[redacted] D:\temporary\msys2\apps\bin D:\msys64\apps64\ruby\bin D:\msys64\mingw64\bin D:\msys64\apps32\gnuwin32\bin D:\msys64\apps32\sysinternals D:\msys64\apps32\scite D:\msys64\apps32\xnview D:\msys64\apps64\mplayer D:\msys64\apps64\php-nts D:\msys64\apps32\fpc\bin\i386-win32 D:\msys64\apps64\ghc\bin D:\msys64\apps32\gnuplot\bin D:\msys64\apps32\miktex\miktex\bin D:\msys64\apps32\octave\bin D:\msys64\apps32\rhino D:\msys64\apps32\spidermonkey D:\msys64\apps32\universalindentgui\indenters D:\msys64\apps32\mono\bin D:\msys64\apps64\java\bin D:\msys64\apps64\gplc\bin D:\msys64\apps64\debugging-tools D:\msys64\apps64\7zip D:\msys64\apps32\v8 D:\msys64\apps32\hstart D:\msys64\apps32\chocolatey\bin D:\msys64\apps32\phpanorl D:\msys64\apps32\php shell D:\msys64\apps32\unison D:\msys64\apps32\git\cmd D:\msys64\apps32\hxd D:\msys64\apps32\notepad++ D:\msys64\apps32\cint C:\Program Files\Microsoft F#\v4.0 C:\Program Files (x86)\Microsoft F#\v4.0 C:\Windows\Microsoft.NET\Framework64\v4.0.30319 Output from D:\cygwin64\bin\id.exe UID: 197609(ether) GID: 197121(None) 197121(None) 197612(Debugger Users) 197613(HelpLibraryUpdaters)578(Hyper-V Administrators) 559(Performance Log Users) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users)15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication) 401408(Medium Mandatory Level) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'ether' PWD = '/cygdrive/w' HOME = '/cygdrive/c/Users/ether' USERDOMAIN_ROAMINGPROFILE = 'onyx' HOMEPATH = '\Users\ether' APPDATA = 'C:\Users\ether\AppData\Roaming' ProgramW6432 = 'C:\Program Files' PACKAGER = 'David Macek ' HOSTNAME = 'onyx' SHELL = '/bin/bash' TERM = 'cygwin' _NT_SYMBOL_PATH = 'symsrv*symsrv.dll*C:\temporary\symbols*http://msdl.microsoft.com/download/symbols' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 58 Stepping 9, GenuineIntel' PROFILEREAD = 'true' WINDIR = 'C:\Windows' !c: = [redacted] PUBLIC = 'C:\Users\
Re: [Mingw-w64-public] How to recognize symlinks in WIN32?
On 15. 1. 2015 4:11, Greg Jung wrote: > Yes I've seen that, if my second post appeared, the symlinks created with > cygwin are the ones giving me trouble. These links are invisible to CMD.exe, > by someone's > design: > > CYGWIN- created links in > Directory of e:\cygwin64\lib\nox > > 03/31/2014 09:39 AM . > 03/31/2014 09:39 AM .. > 07/01/2013 03:24 AM 336,710 libXpm-noX.a > 07/01/2013 03:24 AM43,690 libXpm-noX.dll.a >2 File(s)380,400 bytes >2 Dir(s) 85,657,726,976 bytes free I think these are cygwin emulated symlinks: They are visible, just not by default. I suspect they are marked with the system attribute. Use "dir /as" to show them. You should see a small size (in order of tens of bytes). You can instruct cygwin to create native NTFS symlinks, but due to a different design, there are some restrictions. See this: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks> > So the question becomes, "why do cygwin symlinks look different, and how can > a user program detect this attribute? I assume you could detect them using cygwin *stat calls. Maybe by compiling against cygwin headers and cygwin1.dll, or maybe by extracting the relevant code from cygwin sources (you'd have to check the relevant licenses). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
