Re: Shares with strange ACL settings
On Aug 13 19:53, Corinna Vinschen wrote: > On Aug 13 18:33, Corinna Vinschen wrote: > > On Aug 12 20:59, Achim Gratz wrote: > > > Corinna Vinschen writes: > > > >> I think so, but there are likely some corner cases. But I think that > > > >> had been proposed and shot down already, so I was trying to come up > > > >> with > > > >> something less intrusive. > > > > > > > > This is relatively unintrusive. The current user token is always > > > > available. So if owner == current user, for every group in the file's > > > > ACL just check if it's in the current user token and, if so, add the > > > > perms of that group to the owner perms. > > > > > > > > Sounds pretty neat as an intermediate solution to me. > > > > > > I'd play the guinea pig for that snapshot… :-) > > > > This puzzles me a bit. As example you gave something like > > [blah] > Oh, I get it. This is *because* the current Cygwin doesn't check > membership of all groups in the ACL. I checked in the change we were talking about. Please give the latest snapshot from https://cygwin.com/snapshots/ a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgfdCERBtGy.pgp Description: PGP signature
Re: 2.2.0:ls segfault:Windows 7(6.1)
Hi Fenn, On Aug 13 11:29, Fenn wrote: > I just updated my cygwin and I am getting a segfault when I do a "ls > -l" on my c drive at the root. > > I don't get this if i do a "ls -l" in my home directory. > > I am including details from strace and info on my install (see below > and attached). > > I also attached the "cygcheck -s -v -r > /tmp/cygcheck.out" file. > > Is there anything else I should report? No idea if you can, unless you try to debug this. >31 75028 [main] ls 5696 acl32: 3 = acl(hiberfil.sys) the acl call succeeded and then... > --- Process 5696, exception c005 at 77BF0DBF ...it crashes with a SEGV in a Windows DLL for some reason not visible from the strace output. It *might* have to do with a failing check on hiberfil.sys, but it could just as well have to do with the next file in the dir or something completely different. I'm not sure I can reproduce this. I have no such effect on amy of my machines. The only obvious difference is that I never hibernate my machines so they don't even have a hiberfil.sys. Assuming you call `ls -l ' once for each file in /cygdrive/c, can you reproduce which file triggers the crash? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpOSkG4Ipu_u.pgp Description: PGP signature
Re: Shares with strange ACL settings
Corinna Vinschen cygwin.com> writes: > I checked in the change we were talking about. Please give the latest > snapshot from https://cygwin.com/snapshots/ a try. I've had a quick look and things look good. I'll have to roll out the snapshot to our server and revert the script changes, but it seems like this should solve the problems I've had (and that forced noacl mounts in most cases -- I've kept additional mounts without noacl for testing purposes that will now come in handy). 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
Re: Shares with strange ACL settings
Marco, please see below in terms of L3 cache info. Thanks, On Aug 14 10:56, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > I checked in the change we were talking about. Please give the latest > > snapshot from https://cygwin.com/snapshots/ a try. > > I've had a quick look and things look good. I'll have to roll out the > snapshot to our server and revert the script changes, but it seems like this > should solve the problems I've had (and that forced noacl mounts in most > cases -- I've kept additional mounts without noacl for testing purposes that > will now come in handy). Cool, thanks for your quick feedback. We should just be aware that this is ultimately a kludge. I think I now finally understand what would have to be done to get a generic solution which results in correct POSIX permission evaluation for any current user and any file ACL. However, from some preliminary testing it seems the generic solution has at least two downsides: - It's slow (AuthZ code, setting up and breaking down user/group contexts for each checked file...) - It would always contact the AD when trying to fetch info for AD users, which is bad for remote machines not or slowly connected to the AD server. Anyway, this isn't pressing so it would be nice if you keep on testing. I'm planning to update to 2.2.1 only after a certain pipe problem just discussed on the #cygwin IRC channel is either fixed or settled any other way, Btw., can you please also check /proc/cpuinfo? As discussed, Cygwin's emulation fell short on L3 cache info. I now added code to fetch L3 cache info as well as correct processor topology information on Intel CPUs. For AMD CPUs the topology and cache info was already fine. Linux does not show L3 cache info for AMD CPUs afaics, so I also didn't add that to Cygwin. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdSDlxU4usy.pgp Description: PGP signature
Re: commands spends time in cygheap_user
I hope, not to follow a red herring again, but found some interesting. I did a fresh cygwin installation again but made an error not to copy my old .bashrc and .bashrc-profile files. Within .bashrc I defined an alias for ls (ls='ls --color=auto --show-control-chars'). I noticed, that the time lag has went away. After a "ls --color=auto", the time lag appeared again. Comparing the strace output with/without the color flag, I found that the time lag at "cygheap_user::ontherange" has gone and it now appeared at a ldap_bind [ldap_init] that was called in the context of a symbolic link to a directory on a network share. The previous strace logs did not show a time lag at this point, only at the cygheap_user entry. I deleted the "ln -s" entry and did not notice this big time lag any more even with the color flag. I restored the "old" v2.2.0 version and cannot find the previous logged time lag. As no files within the cygwin directory structure has been modified, it seems, that some registry information has been "healed" by the multiple fresh installations. PS: To do a fresh install I did a "backup" by renaming the original cygwin folder. The "restore" was done by renaming the fresh installed cygwin folder and renaming the previous "backuped" folder back to cygwin. For me the issue is now closed. Thanks for your input. Regards, Matthias -- View this message in context: http://cygwin.1069669.n5.nabble.com/commands-spends-time-in-cygheap-user-tp119766p120519.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: commands spends time in cygheap_user
On Aug 10 18:01, Corinna Vinschen wrote: > On Aug 10 05:00, mku wrote: > > Oh, sorry. I did a fresh 2.2 install to avoid side effects from my previous > > updated one and forgot to modify the nsswitch.conf. After correcting it, the > > result now is the same from the time aspect but loading of the net dlls have > > now disappeared as expected. > > +++ 8< - > > 280 44318 [main] ls 181944 client_request::make_request: cygserver > > un-availa > > --- Process 181944 loaded C:\Windows\SysWOW64\advapi32.dll at 7540 > > --- Process 181944 loaded C:\Windows\SysWOW64\msvcrt.dll at 76CB > > --- Process 181944 loaded C:\Windows\SysWOW64\sechost.dll at 76A0 > > --- Process 181944 loaded C:\Windows\SysWOW64\rpcrt4.dll at 7530 > > --- Process 181944 loaded C:\Windows\SysWOW64\sspicli.dll at 750C > > --- Process 181944 loaded C:\Windows\SysWOW64\cryptbase.dll at 750B > > --- Process 181944 thread 186236 created > > 4525052 4569370 [main] ls 181944 cygheap_user::ontherange: what 2, pw > > 0x612FFCF0 > > 302 4569672 [main] ls 181944 cygheap_user::ontherange: HOME is already in > > the > > --- 8< - > > I don't know how the delta time is calculated. As the time lag is always > > printed after loading the dlls, it may be that the log message is printed > > after the logged step has been completed. If that is true, the time lag may > > occur while loading one of the dlls or creating the thread. > > > > As I mentioned before the same command repeated one second again shows > > normal behaviour (0.406s). > > +++ 8< - > > 106 20307 [main] ls 201132 client_request::make_request: cygserver > > un-availa > > --- Process 201132 loaded C:\Windows\SysWOW64\advapi32.dll at 7540 > > --- Process 201132 loaded C:\Windows\SysWOW64\msvcrt.dll at 76CB > > --- Process 201132 loaded C:\Windows\SysWOW64\sechost.dll at 76A0 > > --- Process 201132 loaded C:\Windows\SysWOW64\rpcrt4.dll at 7530 > > --- Process 201132 loaded C:\Windows\SysWOW64\sspicli.dll at 750C > > --- Process 201132 loaded C:\Windows\SysWOW64\cryptbase.dll at 750B > > --- Process 201132 thread 201240 created > > 9195 29502 [main] ls 201132 cygheap_user::ontherange: what 2, pw > > 0x612FFCF0 > >95 29597 [main] ls 201132 cygheap_user::ontherange: HOME is already in > > the > > --- 8< - > > If you wait a longer period (e.g. 5 minutes), the first (longer) behaviour > > is shown. > > As this time lag is not seen with Version 1.7.28 on the same machine, I > > assume that it has come with Version 2.2. > > Well, it might have been introduced by *any* version later than 1.7.28. > It's very unlikley that this has been introduced by 2.2.0. From the > above output it's not clear where it hangs. I'll try to reproduce it > later this week. Except, I can't. Under the same circumstances, with nsswitch.conf passwd: files group: files and the network connection to my AD disabled, I don't encounter any noticable lag, not even after waiting a long time to get rid of potentially cached info. Any chance this behaviour is triggered by some virus scanner or something like that? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpGkKet51n0q.pgp Description: PGP signature
Cygwin version detection at run time
Hi. I am trying to find out Cygwin version at run time. I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API for this. However, it seems that the `cygwin_version_info` structure this call is supposed to fill in is not publicly available and is only declared internally in `winsup/cygwin/cygwin_version.h`. Am I right that my only option is either to copy the internal declaration of the structure or to use `/proc/version` and parse the version string out of that? -- VH -- 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: Cygwin version detection at run time
On 8/14/2015 9:56 AM, Václav Haisman wrote: Hi. I am trying to find out Cygwin version at run time. I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API for this. However, it seems that the `cygwin_version_info` structure this call is supposed to fill in is not publicly available and is only declared internally in `winsup/cygwin/cygwin_version.h`. Am I right that my only option is either to copy the internal declaration of the structure or to use `/proc/version` and parse the version string out of that? There's uname, whose options allow getting various parts of what /proc/version gives you. uname is also somewhat portable across different flavors of linux ... Eliot Moss -- 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: Cygwin version detection at run time
On 14 August 2015 at 16:11, Eliot Moss wrote: > On 8/14/2015 9:56 AM, Václav Haisman wrote: >> >> Hi. >> >> I am trying to find out Cygwin version at run time. >> >> I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API >> for this. However, it seems that the `cygwin_version_info` structure >> this call is supposed to fill in is not publicly available and is only >> declared internally in `winsup/cygwin/cygwin_version.h`. >> >> Am I right that my only option is either to copy the internal >> declaration of the structure or to use `/proc/version` and parse the >> version string out of that? > > > There's uname, whose options allow getting various parts of what > /proc/version gives you. uname is also somewhat portable across > different flavors of linux ... Never mind, I have figured it out. The `cygwin_internal (CW_GETVERSIONINFO)` actually returns a pointer to string which can be parsed reliably. I have used it. -- VH -- 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: Cygwin version detection at run time
On Aug 14 17:08, Václav Haisman wrote: > On 14 August 2015 at 16:11, Eliot Moss wrote: > > On 8/14/2015 9:56 AM, Václav Haisman wrote: > >> > >> Hi. > >> > >> I am trying to find out Cygwin version at run time. > >> > >> I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API > >> for this. However, it seems that the `cygwin_version_info` structure > >> this call is supposed to fill in is not publicly available and is only > >> declared internally in `winsup/cygwin/cygwin_version.h`. > >> > >> Am I right that my only option is either to copy the internal > >> declaration of the structure or to use `/proc/version` and parse the > >> version string out of that? > > > > > > There's uname, whose options allow getting various parts of what > > /proc/version gives you. uname is also somewhat portable across > > different flavors of linux ... > > Never mind, I have figured it out. The `cygwin_internal > (CW_GETVERSIONINFO)` actually returns a pointer to string which can > be parsed reliably. I have used it. cygwin_internal(CW_GETVERSIONINFO) is an API for non-Cygwin tools like cygcheck, not for general consumption. For a Cygwin executable, better use uname(2) instead. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpLU_d2ttK2o.pgp Description: PGP signature
Re: commands spends time in cygheap_user
On Aug 14 06:49, mku wrote: > I hope, not to follow a red herring again, but found some interesting. > > I did a fresh cygwin installation again but made an error not to copy my old > .bashrc and .bashrc-profile files. > Within .bashrc I defined an alias for ls (ls='ls --color=auto > --show-control-chars'). > I noticed, that the time lag has went away. After a "ls --color=auto", the > time lag appeared again. > Comparing the strace output with/without the color flag, I found that the > time lag at "cygheap_user::ontherange" has gone and it now appeared at a > ldap_bind [ldap_init] that was called in the context of a symbolic link to a > directory on a network share. The previous strace logs did not show a time > lag at this point, only at the cygheap_user entry. > > I deleted the "ln -s" entry and did not notice this big time lag any more > even with the color flag. > > I restored the "old" v2.2.0 version and cannot find the previous logged time > lag. > As no files within the cygwin directory structure has been modified, it > seems, that some registry information has been "healed" by the multiple > fresh installations. > > PS: To do a fresh install I did a "backup" by renaming the original cygwin > folder. The "restore" was done by renaming the fresh installed cygwin folder > and renaming the previous "backuped" folder back to cygwin. > > For me the issue is now closed. Thanks for your input. Thank you for this important point. That gives me an idea what happens and I guess this is something which needs fixing. These checks should also only happen if passwd/group in nsswitch.conf are set to "db". Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp6ENMlmwX7T.pgp Description: PGP signature
Re: Re: Hide fbpanel icon
On 2015-08-13 11:33, Yaakov Selkowitz wrote: > On Thu, 2015-08-13 at 10:46 -0700, AC wrote: >> On 2015-08-13 10:06, Jon TURNEY wrote: >>> If your /etc/X11/xinit/startxwinrc mentions fbpanel, you don't have >>> the latest version (see [1]), so maybe try updating or reinstalling >>> the xinit package? >>> >>> If you have a custom ~/.startxwinrc, then base it on the current >>> /etc/X11/xinit/startxwinrc and end it with 'exec >>> /usr/bin/xwin-xdg-menu', or even 'exec sleep infinity' if you don't >>> like that. >>> >>> [1] https://cygwin.com/ml/cygwin-announce/2015-07/msg00013.html >> >> Interesting, I'm using the global startxwinrc and my xinit package is >> already 1.3.4-9 yet fbpanel is still in there and there's no mention >> of xwin-xdg-menu in it yet I do have xwin-xdg-menu installed >> (20150708-1). >> I do not have a custom startxwinrc in my home directory. > > Then you must have customized your global startxwinrc, in which case it > would not have been replaced when upgrading to 1.3.4-9. Replacing it > with the copy under /etc/defaults should fix this. > Yes, it is fixed. It had been quite some time since I edited the file. I'm more accustomed to package managers warning me about customized files when they detect them. -- 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: Shares with strange ACL settings
Corinna Vinschen writes: > Cool, thanks for your quick feedback. Thanks for the snapshot! > We should just be aware that this is ultimately a kludge. I think I now > finally understand what would have to be done to get a generic solution > which results in correct POSIX permission evaluation for any current > user and any file ACL. However, from some preliminary testing it seems > the generic solution has at least two downsides: > > - It's slow (AuthZ code, setting up and breaking down user/group contexts > for each checked file...) > > - It would always contact the AD when trying to fetch info for AD users, > which is bad for remote machines not or slowly connected to the AD server. I think we've came to the same conclusion (modulo the question of whether AuthZ would be usable for this) some time ago. My personal take on this is that the "kludge" is likely better than both what we had before and the result of the pre-snapshot ACL evaluation. If that also solves the problem of denying oneself file access by simply copying a file with carefully crafted ACL, then I would say it's good enough for most circumstances. Probably not good enough to pass the Perl filemode tests during build, but they have some problems in their design anyway. > Anyway, this isn't pressing so it would be nice if you keep on > testing. As I said, I need some time next week to switch things into a mode where problems could potentially show up. I don't expect any, but I don't pretend to understand all the edge cases completely either. > I'm planning to update to 2.2.1 only after a certain pipe problem just > discussed on the #cygwin IRC channel is either fixed or settled any > other way, > > Btw., can you please also check /proc/cpuinfo? Yes, I have both AMD and Intel machines I can test this with. > As discussed, Cygwin's emulation fell short on L3 cache info. I now > added code to fetch L3 cache info as well as correct processor topology > information on Intel CPUs. For AMD CPUs the topology and cache > info was already fine. Linux does not show L3 cache info for AMD CPUs > afaics, so I also didn't add that to Cygwin. I can't test this with a new enough kernel for AMD, but perhaps someone is testing some new iron/OS combination and I can get that information from them. For Intel since some time the L3 cache size is shown (older kernels would show you the per-node L2 cache size IIRC). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Shares with strange ACL settings
On Aug 14 20:25, Achim Gratz wrote: > Corinna Vinschen writes: > > Btw., can you please also check /proc/cpuinfo? > > Yes, I have both AMD and Intel machines I can test this with. > > > As discussed, Cygwin's emulation fell short on L3 cache info. I now > > added code to fetch L3 cache info as well as correct processor topology > > information on Intel CPUs. For AMD CPUs the topology and cache > > info was already fine. Linux does not show L3 cache info for AMD CPUs > > afaics, so I also didn't add that to Cygwin. > > I can't test this with a new enough kernel for AMD, but perhaps someone > is testing some new iron/OS combination and I can get that information > from them. For Intel since some time the L3 cache size is shown (older > kernels would show you the per-node L2 cache size IIRC). Recent kernels as well. I just tested this with a 4.1.4 kernel, and the source code of the upstream master branch shows no changes in terms of the cache info on AMD CPUs. A bit surprising, considering that the L3 cache info is apparently available using the same CPUID leaf. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpINz7JjgTA1.pgp Description: PGP signature
Re: run.exe fails to start XWin on Windows 8.1 through the shortcut
Achim, let's hope that your update helps. In the meantime, using run version 1.3.3-1: 1) Issuing C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; /usr/bin/startxwin" from cmd does not start an Xwin server; no error message is produced. 2) Issuing run.exe --quote /usr/bin/bash.exe -l -c "cd; /usr/bin/startxwin" from cygwin64 text console (mintty with some arguments) does start an Xwin Server. (Xterm has to be started separately afterwards, but let's hope that this is a different issue.) Best, Jaakov. -- 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: commands spends time in cygheap_user
On Aug 14 17:48, Corinna Vinschen wrote: > On Aug 14 06:49, mku wrote: > > I hope, not to follow a red herring again, but found some interesting. > > > > I did a fresh cygwin installation again but made an error not to copy my old > > .bashrc and .bashrc-profile files. > > Within .bashrc I defined an alias for ls (ls='ls --color=auto > > --show-control-chars'). > > I noticed, that the time lag has went away. After a "ls --color=auto", the > > time lag appeared again. > > Comparing the strace output with/without the color flag, I found that the > > time lag at "cygheap_user::ontherange" has gone and it now appeared at a > > ldap_bind [ldap_init] that was called in the context of a symbolic link to a > > directory on a network share. The previous strace logs did not show a time > > lag at this point, only at the cygheap_user entry. > > > > I deleted the "ln -s" entry and did not notice this big time lag any more > > even with the color flag. > > > > I restored the "old" v2.2.0 version and cannot find the previous logged time > > lag. > > As no files within the cygwin directory structure has been modified, it > > seems, that some registry information has been "healed" by the multiple > > fresh installations. > > > > PS: To do a fresh install I did a "backup" by renaming the original cygwin > > folder. The "restore" was done by renaming the fresh installed cygwin folder > > and renaming the previous "backuped" folder back to cygwin. > > > > For me the issue is now closed. Thanks for your input. > > Thank you for this important point. That gives me an idea what > happens and I guess this is something which needs fixing. These > checks should also only happen if passwd/group in nsswitch.conf > are set to "db". I just checked in a patch to address this issue, and I just created a new developer snapshot for testing. Can you reproduce the situation by recreating the symlink and try again? If you can reproduce it, can you give the latest Cygwin DLL from the developer snapshot page https://cygwin.com/snapshots/ a try? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp5AEEVkYaqz.pgp Description: PGP signature
Re: Hide fbpanel icon
Greetings, AC! >>> Interesting, I'm using the global startxwinrc and my xinit package is >>> already 1.3.4-9 yet fbpanel is still in there and there's no mention >>> of xwin-xdg-menu in it yet I do have xwin-xdg-menu installed >>> (20150708-1). >>> I do not have a custom startxwinrc in my home directory. >> >> Then you must have customized your global startxwinrc, in which case it >> would not have been replaced when upgrading to 1.3.4-9. Replacing it >> with the copy under /etc/defaults should fix this. >> > Yes, it is fixed. It had been quite some time since I edited the file. > I'm more accustomed to package managers warning me about customized > files when they detect them. Cygwin's setup routine could use some love, there's no denying of that. However, Someone Has To Do It. http://cygwin.com/acronyms/#SHTDI -- With best regards, Andrey Repin Saturday, August 15, 2015 03:47:57 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run.exe fails to start XWin on Windows 8.1 through the shortcut
Jaakov Jaakov writes: > 1) Issuing > C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; > /usr/bin/startxwin" > from cmd does not start an Xwin server; no error message is produced. You don't get a stackdump? > 2) Issuing run.exe --quote /usr/bin/bash.exe -l -c "cd; /usr/bin/startxwin" > from cygwin64 text console (mintty with some arguments) does start an > Xwin Server. (Xterm has to be started separately afterwards, but let's > hope that this is a different issue.) It is. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: Hide fbpanel icon
Andrey Repin writes: >> Yes, it is fixed. It had been quite some time since I edited the file. >> I'm more accustomed to package managers warning me about customized >> files when they detect them. > > Cygwin's setup routine could use some love, there's no denying of that. > However, Someone Has To Do It. http://cygwin.com/acronyms/#SHTDI In that case, though, it's not setup. The check of whether the defaults can be replaced because the files have not been edited is in the preremove scripts. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- 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
