Re: mktime call hangs on Cygwin 1.7.30, Windows 7 32 bit
On Tue, Sep 02, 2014 at 01:32:29PM +0200, Marco Atzeri wrote:
On 02/09/2014 13:10, Alexey Shumkin wrote:
Prelude.
I use self-compiled Git (v2.x) on Cygwin (v1.7.30).
Sometimes Git v2.0.4 hung while performing
git prune --expire 2.weeks.ago
I have investigated while debugging that `mktime` call hung.
But that was an avoidable bug (skip prune - and all is ok). So, I've not
reported it.
But after updating Git to v2.1.0
git commit --amend -C HEAD --date=''
hangs, too. And now it is the often used operation by me.
So, I've made a simple example (copied from Git sources) to reproduce
the error.
$ cat cygwin-mktime-bug.c
#include time.h
#include string.h
#include stdio.h
int main(int argc, char **argv)
{
struct tm tm;
memset(tm, 0, sizeof(tm));
tm.tm_year = -1;
tm.tm_mon = -1;
tm.tm_mday = -1;
tm.tm_isdst = -1;
tm.tm_hour = -1;
tm.tm_min = -1;
tm.tm_sec = -1;
printf(Working...\n);
time_t temp_time = mktime(tm);
printf(Worked);
- printf(Worked);
- printf(Worked\n);
}
$ gcc cygwin-mktime-bug.c -o cygwin-mktime-bug -I/usr/include -g
$ ./cygwin-mktime-bug.exe
Working...
no issue on my side.
I've tested on another machines with Cygwin v1.7.11 and v1.7.25. And it
worked. That`s Ok.
Also, I've run ./cygwin-mktime-bug.exe in CMD, and SUPRISINGLY it
worked, but when I run the SAME `cygwin-mktime-bug.exe` in `bash -l -i` it does
not!
Ha-ha! After I've wrote text above, I've tested run `cygwin-mktime-bug.exe`
in `bash`, `bash -i`, `bash -l` AND(!) it worked well in first TWO
cases (`bash` `bash -i`), and DOES NOT in `bash -l`.
How can it be? 8-O
$ LIMIT=1000
$ for ((a=1 ; a = LIMIT ; a++ )); do ./cygwin-mktime-bug.exe ; done
Working...
Worked
...
Working...
Worked
$
So, there is a question: how to fix it?
Nota bene: I do not want to use Cygwin x64 (there were no exim when I've
tested it).
32 bit here.
$ uname -svr
CYGWIN_NT-6.1-WOW64 1.7.32(0.274/5/3) 2014-08-13 23:03
please update to 1.7.32 and than follows:
https://cygwin.com/problems.html
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
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
mktime call hangs on Cygwin 1.7.30, Windows 7 32 bit
Prelude.
I use self-compiled Git (v2.x) on Cygwin (v1.7.30).
Sometimes Git v2.0.4 hung while performing
git prune --expire 2.weeks.ago
I have investigated while debugging that `mktime` call hung.
But that was an avoidable bug (skip prune - and all is ok). So, I've not
reported it.
But after updating Git to v2.1.0
git commit --amend -C HEAD --date=''
hangs, too. And now it is the often used operation by me.
So, I've made a simple example (copied from Git sources) to reproduce
the error.
$ cat cygwin-mktime-bug.c
#include time.h
#include string.h
#include stdio.h
int main(int argc, char **argv)
{
struct tm tm;
memset(tm, 0, sizeof(tm));
tm.tm_year = -1;
tm.tm_mon = -1;
tm.tm_mday = -1;
tm.tm_isdst = -1;
tm.tm_hour = -1;
tm.tm_min = -1;
tm.tm_sec = -1;
printf(Working...\n);
time_t temp_time = mktime(tm);
printf(Worked);
}
$ gcc cygwin-mktime-bug.c -o cygwin-mktime-bug -I/usr/include -g
$ ./cygwin-mktime-bug.exe
Working...
So, there is a question: how to fix it?
Nota bene: I do not want to use Cygwin x64 (there were no exim when I've tested
it).
--
Alexey Shumkin
--
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: mktime call hangs on Cygwin 1.7.30, Windows 7 32 bit
On Sep 2 15:10, Alexey Shumkin wrote:
Prelude.
I use self-compiled Git (v2.x) on Cygwin (v1.7.30).
Sometimes Git v2.0.4 hung while performing
git prune --expire 2.weeks.ago
I have investigated while debugging that `mktime` call hung.
But that was an avoidable bug (skip prune - and all is ok). So, I've not
reported it.
But after updating Git to v2.1.0
git commit --amend -C HEAD --date=''
hangs, too. And now it is the often used operation by me.
So, I've made a simple example (copied from Git sources) to reproduce
the error.
$ cat cygwin-mktime-bug.c
#include time.h
#include string.h
#include stdio.h
int main(int argc, char **argv)
{
struct tm tm;
memset(tm, 0, sizeof(tm));
tm.tm_year = -1;
tm.tm_mon = -1;
tm.tm_mday = -1;
tm.tm_isdst = -1;
tm.tm_hour = -1;
tm.tm_min = -1;
tm.tm_sec = -1;
printf(Working...\n);
time_t temp_time = mktime(tm);
printf(Worked);
}
$ gcc cygwin-mktime-bug.c -o cygwin-mktime-bug -I/usr/include -g
$ ./cygwin-mktime-bug.exe
Working...
Works fine for me every time on Cygwin 1.7.32 32 and 64 bit. I ran
your testcase 1000 times in a loop. It's slow, but it never hangs.
Btw., the code of mktime and low level stuff is basically identical
to the NetBSD implementation it has been taken from.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpqPGASc8Lg7.pgp
Description: PGP signature
Re: mktime call hangs on Cygwin 1.7.30, Windows 7 32 bit
On 02/09/2014 13:10, Alexey Shumkin wrote:
Prelude.
I use self-compiled Git (v2.x) on Cygwin (v1.7.30).
Sometimes Git v2.0.4 hung while performing
git prune --expire 2.weeks.ago
I have investigated while debugging that `mktime` call hung.
But that was an avoidable bug (skip prune - and all is ok). So, I've not
reported it.
But after updating Git to v2.1.0
git commit --amend -C HEAD --date=''
hangs, too. And now it is the often used operation by me.
So, I've made a simple example (copied from Git sources) to reproduce
the error.
$ cat cygwin-mktime-bug.c
#include time.h
#include string.h
#include stdio.h
int main(int argc, char **argv)
{
struct tm tm;
memset(tm, 0, sizeof(tm));
tm.tm_year = -1;
tm.tm_mon = -1;
tm.tm_mday = -1;
tm.tm_isdst = -1;
tm.tm_hour = -1;
tm.tm_min = -1;
tm.tm_sec = -1;
printf(Working...\n);
time_t temp_time = mktime(tm);
printf(Worked);
- printf(Worked);
- printf(Worked\n);
}
$ gcc cygwin-mktime-bug.c -o cygwin-mktime-bug -I/usr/include -g
$ ./cygwin-mktime-bug.exe
Working...
no issue on my side.
$ LIMIT=1000
$ for ((a=1 ; a = LIMIT ; a++ )); do ./cygwin-mktime-bug.exe ; done
Working...
Worked
...
Working...
Worked
$
So, there is a question: how to fix it?
Nota bene: I do not want to use Cygwin x64 (there were no exim when I've tested
it).
32 bit here.
$ uname -svr
CYGWIN_NT-6.1-WOW64 1.7.32(0.274/5/3) 2014-08-13 23:03
please update to 1.7.32 and than follows:
https://cygwin.com/problems.html
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
problems with installing cygwin on windows 7
Could anyone help me with this problem? I posted this couple of days ago, but so far there is no response. When installing cygwin using default option - everything goes well. On the other hand when trying to install: everything (install option) or some parts of the cygwin package the setup.exe runs for ever and could not complete successfully within 3-5 hours. So I stopped it manually. I tried to do that using various download sites and it does not help. I am trying to install cygwin as a first package on freshly installed windows 7. Is anyone experiencing similar problems? What the remedy could be? Thanks in advance Piotr -- 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: problems with installing cygwin on windows 7
Hi Piotr ! 2013/5/3 Piotr Cieplak piotr_ciep...@yahoo.com: Could anyone help me with this problem? I posted this couple of days ago, but so far there is no response. When installing cygwin using default option - everything goes well. On the other hand when trying to install: everything (install option) or some parts of the cygwin package the setup.exe runs for ever and could not complete successfully within 3-5 hours. So I stopped it manually. I tried to do that using various download sites and it does not help. I am trying to install cygwin as a first package on freshly installed windows 7. Is anyone experiencing similar problems? What the remedy could be? Thanks in advance I was able to install Cygwin into the following PCs on 2013-03-2x . https://dl.dropboxusercontent.com/u/86335040/openSUSE/DxDiag13.txt I have remembered that setup.exe required install of Bonjour. Then, I installed Safari previously. Although it is right or cannot judge to me, since it may become helpful, I tell. -- 1xx itsa...@gmail.com https://twitter.com/ItSANgo http://d.hatena.ne.jp/Itisango/ -- 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: problems with installing cygwin on windows 7
Hi Piotr, On Fri, May 3, 2013 at 8:25 AM, Piotr Cieplak wrote: Could anyone help me with this problem? I posted this couple of days ago, but so far there is no response. When installing cygwin using default option - everything goes well. On the other hand when trying to install: everything (install option) or some parts of the cygwin package the setup.exe runs for ever and could not complete successfully within 3-5 hours. (snip) Is anyone experiencing similar problems? What the remedy could be? Don't do it :) For setup.exe to to install everything it has to download everything, checksum everything, unpack everything, install everything, rebase everything. This takes time, regardless of which mirror you use. Why do you want to install everything? I doubt there is a single person on Earth who has used every single Cygwin program. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: problems with installing cygwin on windows 7
On Fri, May 03, 2013 at 09:44:19AM +0200, Csaba Raduly wrote: Hi Piotr, On Fri, May 3, 2013 at 8:25 AM, Piotr Cieplak wrote: Could anyone help me with this problem? I posted this couple of days ago, but so far there is no response. When installing cygwin using default option - everything goes well. On the other hand when trying to install: everything (install option) or some parts of the cygwin package the setup.exe runs for ever and could not complete successfully within 3-5 hours. (snip) Is anyone experiencing similar problems? What the remedy could be? Don't do it :) For setup.exe to to install everything it has to download everything, checksum everything, unpack everything, install everything, rebase everything. This takes time, regardless of which mirror you use. Why do you want to install everything? I doubt there is a single person on Earth who has used every single Cygwin program. But, if they did, I'd give them a gold star for their efforts. cgf -- 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: problems with installing cygwin on windows 7
On 03/05/2013 11:48 AM, Christopher Faylor wrote: On Fri, May 03, 2013 at 09:44:19AM +0200, Csaba Raduly wrote: Hi Piotr, On Fri, May 3, 2013 at 8:25 AM, Piotr Cieplak wrote: Could anyone help me with this problem? I posted this couple of days ago, but so far there is no response. When installing cygwin using default option - everything goes well. On the other hand when trying to install: everything (install option) or some parts of the cygwin package the setup.exe runs for ever and could not complete successfully within 3-5 hours. (snip) Is anyone experiencing similar problems? What the remedy could be? Don't do it :) For setup.exe to to install everything it has to download everything, checksum everything, unpack everything, install everything, rebase everything. This takes time, regardless of which mirror you use. Why do you want to install everything? I doubt there is a single person on Earth who has used every single Cygwin program. But, if they did, I'd give them a gold star for their efforts. Define use ... for f in /usr/bin/*.exe; do $f --help; done :) Ryan -- 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: problems with installing cygwin on windows 7
On Thu, May 2, 2013 at 11:25 PM, Piotr Cieplak piotr_ciep...@yahoo.com wrote: Could anyone help me with this problem? I posted this couple of days ago, but so far there is no response. When installing cygwin using default option - everything goes well. On the other hand when trying to install: everything (install option) or some parts of the cygwin package the setup.exe runs for ever and could not complete successfully within 3-5 hours. So I stopped it manually. I tried to do that using various download sites and it does not help. I am trying to install cygwin as a first package on freshly installed windows 7. Is anyone experiencing similar problems? What the remedy could be? Thanks in advance Piotr Hi Piotr, I have installed reinstalled Cygwin recently (and over the past 12 years). If you got the default version of Cygwin to install correctly, there is no problem with your computer, etc. A full install might take 12 hours, so be patient. Also, I have found that the kernel.org mirror is much faster than the anl.gov mirror I had previously used. A faster option might to use 2-3 steps: 1. Do a full download and save but don't install. 2. Do a basic (default) install from the saved files. This helps to verify that the download worked without any glitches (the connection from the mirror through the internet, your ISP, the Setup.exe program and your computer aren't perfect...sometimes things get garbled). 3. Do a few quick tests to see that the basic install worked (open a shell window and run ls -l, etc). Assuming that works, re-run Setup.exe and select a few more individual packages for a full install (maybe compilers, editors, etc). Even with just a few things, the postinstall scripts can still take a couple of hours to finish things off, so be prepared and don't kill them before they're finished. Repeat as necessary until everything you actually use is installed. If something goes wrong, you still have the saved download and don't need to repeat step #1. Just delete the c:/cygwin dir and start over at step 2. Enjoy! And thank you once again to the entire Cygwin team for helping those of us who are still stuck interacting with Windoze. ;) Alan Thompson P.S. I have had to run rebaseall each time I do an install or upgrade over the past year.not sure why as this never used to be a problem. Please see: http://cygwin.wikia.com/wiki/Rebaseall It is only a 5 minute process once you have the correct instructions. -- 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: problems with installing cygwin on windows 7
On 03/05/2013 2:28 PM, Alan Thompson wrote: P.S. I have had to run rebaseall each time I do an install or upgrade over the past year.not sure why as this never used to be a problem. That's very strange, because setup.exe started running rebaseall automatically just over a year ago [1]. You shouldn't need to run rebaseall these days unless you compile your own .dlls and want them to play nice with the rest of the system. Please see: http://cygwin.wikia.com/wiki/Rebaseall It is only a 5 minute process once you have the correct instructions. Where correct means accurate and up to date?*** Please don't use those instructions, even if they are a the very top of the Google listing for cygwin setup rebaseall. First, rebaseall runs automatically as part of setup for over a year now [1]. Second, rebooting into safe mode to stop cygwin services borders on downright silly. Third, you don't need to be Administrator to run rebase unless you messed with file permissions in really weird ways. Fourth, somebody *is* working on a 64-bit port of cygwin; it mostly works at this point, and somebody posted about using it just today in fact [2]. [1] http://cygwin.com/ml/cygwin-announce/2012-03/msg00060.html [2] http://cygwin.com/ml/cygwin/2013-05/msg00055.html *** but then again, the official documentation at /usr/share/doc/rebase/README still says: Note that rebaseall is only a stop-gap measure. Eventually the rebase functionality will be added to Cygwin's setup.exe, so that rebasing will happen automatically. ... but at least it doesn't tell you to reboot into safe mode as part of using Cygwin. Ryan -- 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: problems with installing cygwin on windows 7
On Fri, May 3, 2013 at 12:03 PM, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: On 03/05/2013 2:28 PM, Alan Thompson wrote: P.S. I have had to run rebaseall each time I do an install or upgrade over the past year.not sure why as this never used to be a problem. That's very strange, because setup.exe started running rebaseall automatically just over a year ago [1]. You shouldn't need to run rebaseall these days unless you compile your own .dlls and want them to play nice with the rest of the system. snip ... but at least it doesn't tell you to reboot into safe mode as part of using Cygwin. I did not boot into safe mode - just a plain reboot as a safety precaution. I then just opened up a regular Windoze cmd.exe window and typed the commands using the dash shell. I cannot explain why I have suddenly needed to run rebaseall to keep Cygwin working, especially since I had thougt that setup.exe handled everything as you state. Last month the corp. IT dept did a windows update and Cygwin quite working. I did a Cygwin reinstall but got the error message (can't remember specifically now) indicating a rebaseall was needed. Rediscovered the rebaseall documentation via google and printed it out to keep at my desk. Fortunately, the simple rebaseall command got the Cygwin installation back up and working smoothly in just a few minutes. Alan Thompson On Fri, May 3, 2013 at 12:03 PM, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: On 03/05/2013 2:28 PM, Alan Thompson wrote: P.S. I have had to run rebaseall each time I do an install or upgrade over the past year.not sure why as this never used to be a problem. That's very strange, because setup.exe started running rebaseall automatically just over a year ago [1]. You shouldn't need to run rebaseall these days unless you compile your own .dlls and want them to play nice with the rest of the system. Please see: http://cygwin.wikia.com/wiki/Rebaseall It is only a 5 minute process once you have the correct instructions. Where correct means accurate and up to date?*** Please don't use those instructions, even if they are a the very top of the Google listing for cygwin setup rebaseall. First, rebaseall runs automatically as part of setup for over a year now [1]. Second, rebooting into safe mode to stop cygwin services borders on downright silly. Third, you don't need to be Administrator to run rebase unless you messed with file permissions in really weird ways. Fourth, somebody *is* working on a 64-bit port of cygwin; it mostly works at this point, and somebody posted about using it just today in fact [2]. [1] http://cygwin.com/ml/cygwin-announce/2012-03/msg00060.html [2] http://cygwin.com/ml/cygwin/2013-05/msg00055.html *** but then again, the official documentation at /usr/share/doc/rebase/README still says: Note that rebaseall is only a stop-gap measure. Eventually the rebase functionality will be added to Cygwin's setup.exe, so that rebasing will happen automatically. ... but at least it doesn't tell you to reboot into safe mode as part of using Cygwin. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: re cygwin on windows 7 missing linux header files
On 10/21/2012 12:20 AM, spaceranger ranger wrote: Hello using cygwin on windows 7 and missing these files when running make sys/socket.h , netinet/in_system.h, netinet/in.h,netinet/ip.h, arpa/inet.h, netdb.h, what to do!? to build what ? How ? in general use the search at http://cygwin.com/packages/ to find the package you are looking for most of the files, you are mentioning, exist on cygwin package Are you looking for usr/include/netinet/in_systm.h instead of in_system.h ? Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
On Wed, May 23, 2012 at 09:12:59PM +0200, marco atzeri wrote: On 5/23/2012 8:47 PM, Bill Ross wrote: what does rebase mean? http://cygwin.random.offsite.place.com/ /usr/share/doc/rebase/README Thanks Marco. PLEASE don't point to off-site unofficial documentation when we have local official documentation. cgf -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
Thank you. We have not, to date, seen any messages about forking problems or dll loading problems. I presume, though, that other behaviors might also indicate this rebase action is needed? On Wed, May 23, 2012 at 3:12 PM, marco atzeri marco.atz...@gmail.com wrote: /usr/share/doc/rebase/README -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.facebook.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -- 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
Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
We are trying to make use of cygwin in several ways on Windows 7 64-bit desktops. One of the first things we have noticed is that there are a lot of processes sitting on the desktop that appear to be related to cygwin that we didn't see previously on 32 bit XP. For instance, if we open a bash console, perform an ssh to another machine, do some work, then close the window, the bash and ssh still seem to be listed when we look at the windows 7 task manager. So, not wanting to duplicate the fine efforts of those on this list from the past few years. I googed for cygwin issues windows 7 64 bit, but the 301,000 results were a bit overwhelming to contemplate reading through to find unique issues that need to be addressed, and of course may or may not reflect the state of the current distribution. So before we start doing weeks of reading of threads, etc. I thought I would ask whether someone has gathered this information together. Thank you -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.facebook.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
On 5/23/2012 9:24 AM, Larry W. Virden wrote: We are trying to make use of cygwin in several ways on Windows 7 64-bit desktops. One of the first things we have noticed is that there are a lot of processes sitting on the desktop that appear to be related to cygwin that we didn't see previously on 32 bit XP. For instance, if we open a bash console, perform an ssh to another machine, do some work, then close the window, the bash and ssh still seem to be listed when we look at the windows 7 task manager. I use cygwin all the time under Windows 7 64-bit and that does not happen to me. Thus it would seem to be particular to your setup, or maybe to the specific version (I've not updated for a few weeks) ... Regards -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
On 5/23/2012 9:24 AM, Larry W. Virden wrote: We are trying to make use of cygwin in several ways on Windows 7 64-bit desktops. One of the first things we have noticed is that there are a lot of processes sitting on the desktop that appear to be related to cygwin that we didn't see previously on 32 bit XP. For instance, if we open a bash console, perform an ssh to another machine, do some work, then close the window, the bash and ssh still seem to be listed when we look at the windows 7 task manager. I have 64-bit Win7 with cygwin, and after a while this sort of thing runs out of resources (errno 11) until I reboot (and then starts up after a few ok runs, as just now): $ find . -name *.java | while read i ; do echo $i x grep foob $i x done 375832787 [main] -bash 6020 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741819, errno 11 -bash: fork: retry: Resource temporarily unavailable -bash: fork: Resource temporarily unavailable And I think I have noticed lots of bash processes hanging around, though not in this instance. $ uname -a CYGWIN_NT-6.1-WOW64 mybox 1.7.13(0.260/5/3) 2012-04-05 12:43 i686 Cygwin Bill -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
The message: fork: Resource temporarily unavailable is often associated with a need to rebase ... EM -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
The message: fork: Resource temporarily unavailable is often associated with a need to rebase ... EM Solved, thanks! Bill -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
EM - what does rebase mean? I tried doing a man rebase but didn't get a man page. On Wed, May 23, 2012 at 1:43 PM, Bill Ross photor...@yahoo.com wrote: The message: fork: Resource temporarily unavailable is often associated with a need to rebase ... EM -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
what does rebase mean? http://cygwin.wikia.com/wiki/Rebaseall -- 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
On 5/23/2012 8:47 PM, Bill Ross wrote: what does rebase mean? http://cygwin.wikia.com/wiki/Rebaseall /usr/share/doc/rebase/README -- 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: enabling /largeaddressaware for cygwin in windows 7 64-bit
On Aug 4 18:17, Charles Wilson wrote: On 8/4/2011 2:17 PM, Corinna Vinschen wrote: On Aug 4 13:37, Charles Wilson wrote: Obviously, the OP would need to pass these 'thru' the gfortran compiler using -Wl,--stack,RESERVE or -Wl,--stack,RESERVE,COMMIT (may not work; there's a problem with both ld and gcc using ',' as a delimiter) Wouldn't that be an option for peflags? It's just some info in the file header... Oh, sure, peflags COULD be extended to twiddle any of the PE header values, although I'm not sure that's something you'd want to do to every .exe on your system (i.e. not peflagsall). PTC... Will do :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
enabling /largeaddressaware for cygwin in windows 7 64-bit
Hello, I am not a programming expert, and i wonder if you could give me some basic advice. I am running cygwin on a 64-bit Dell XPS, running Windows 7, with a Core i5 processor, and 12 GB of RAM installed. The fortran 90 code I am running keeps running out of memory (virtual memory or stack overflow errors) on jobs that the computer should easily handle. I have increased the paging memory to 36 MB, but I am afraid that CygWin is still being limited to ~ 1 GB of memory. My problem is very similar to what is described here: http://cygwin.com/ml/cygwin/2011-01/msg00196.html I followed the instructions at [1] and [2] to increase the heap chunk available to cygwin, but I have also read that adding a /largeaddressaware link might further increase the amount of memory available to cygwin (see [3], which confused me a lot). I have not been able to find clear instructions about how to do this for cygwin, could you help? Also, I am interested in any tips about how to maximize the amount of memory available to cygwin given my 64-bit windows 7 setup! Thanks very much for your kind help to a very helpless geologist! Will Amidon [1] http://www.cygwin.com/cygwin-ug-net/setup-maxmem.html [2] http://cygwin.com/ml/cygwin/2010-04/msg00983.html [3] http://www.cygwin.com/ml/cygwin-developers/2011-06/msg2.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
Re: enabling /largeaddressaware for cygwin in windows 7 64-bit
On Aug 4 15:19, Amidon, William H. wrote: Hello, I am not a programming expert, and i wonder if you could give me some basic advice. I am running cygwin on a 64-bit Dell XPS, running Windows 7, with a Core i5 processor, and 12 GB of RAM installed. The fortran 90 code I am running keeps running out of memory (virtual memory or stack overflow errors) on jobs that the computer should The main thread has a 2 Megs stack by default (Windows default). If you're running out of stack space, there's not much we can do. There's some way to define the default stacksize in the executable header but off the top of my head I don't know how to change it. easily handle. I have increased the paging memory to 36 MB, but I am afraid that CygWin is still being limited to ~ 1 GB of memory. It's not. It's limited to 2 Gigs usually, being a 32 bit DLL. Only by setting the large address awareness flag in the executable (not the DLL!) you get a max of 4 Gigs of memory on 64 bit Windows. My problem is very similar to what is described here: http://cygwin.com/ml/cygwin/2011-01/msg00196.html I followed the instructions at [1] and [2] to increase the heap chunk [2]? That's not for 64 bit Windows. If you tried that, take it back. available to cygwin, but I have also read that adding a /largeaddressaware link might further increase the amount of memory available to cygwin (see [3], which confused me a lot). If that confused you, you should probably not tamper with these settings. The maximum you should try is this: - Revert the settings from [1]. - Download the latest Cygwin developer snapshot (only the DLL) from http://cygwin.com/snapshots. - peflags --bigaddr=1 your_executable.exe If that doesn't help, you're out of luck. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: enabling /largeaddressaware for cygwin in windows 7 64-bit
On 8/4/2011 11:53 AM, Corinna Vinschen wrote: On Aug 4 15:19, Amidon, William H. wrote: The fortran 90 code I am running keeps running out of memory (virtual memory or stack overflow errors) on jobs that the computer should The main thread has a 2 Megs stack by default (Windows default). If you're running out of stack space, there's not much we can do. There's some way to define the default stacksize in the executable header but off the top of my head I don't know how to change it. The linker options: `--stack RESERVE' `--stack RESERVE,COMMIT' Specify the number of bytes of memory to reserve (and optionally commit) to be used as stack for this program. The default is 2Mb reserved, 4K committed. [This option is specific to the i386 PE targeted port of the linker] Obviously, the OP would need to pass these 'thru' the gfortran compiler using -Wl,--stack,RESERVE or -Wl,--stack,RESERVE,COMMIT (may not work; there's a problem with both ld and gcc using ',' as a delimiter) -- Chuck -- 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: enabling /largeaddressaware for cygwin in windows 7 64-bit
On Aug 4 13:37, Charles Wilson wrote: On 8/4/2011 11:53 AM, Corinna Vinschen wrote: On Aug 4 15:19, Amidon, William H. wrote: The fortran 90 code I am running keeps running out of memory (virtual memory or stack overflow errors) on jobs that the computer should The main thread has a 2 Megs stack by default (Windows default). If you're running out of stack space, there's not much we can do. There's some way to define the default stacksize in the executable header but off the top of my head I don't know how to change it. The linker options: `--stack RESERVE' `--stack RESERVE,COMMIT' Specify the number of bytes of memory to reserve (and optionally commit) to be used as stack for this program. The default is 2Mb reserved, 4K committed. [This option is specific to the i386 PE targeted port of the linker] Obviously, the OP would need to pass these 'thru' the gfortran compiler using -Wl,--stack,RESERVE or-Wl,--stack,RESERVE,COMMIT (may not work; there's a problem with both ld and gcc using ',' as a delimiter) Wouldn't that be an option for peflags? It's just some info in the file header... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: enabling /largeaddressaware for cygwin in windows 7 64-bit
On 8/4/2011 2:17 PM, Corinna Vinschen wrote: On Aug 4 13:37, Charles Wilson wrote: Obviously, the OP would need to pass these 'thru' the gfortran compiler using -Wl,--stack,RESERVE or -Wl,--stack,RESERVE,COMMIT (may not work; there's a problem with both ld and gcc using ',' as a delimiter) Wouldn't that be an option for peflags? It's just some info in the file header... Oh, sure, peflags COULD be extended to twiddle any of the PE header values, although I'm not sure that's something you'd want to do to every .exe on your system (i.e. not peflagsall). PTC... -- Chuck -- 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
Divergent file system contents, Cygwin versus Windows 7
I am seeing two different versions of a file depending on how I access it. Specifically, the file C:\Program Files (x86)\Vim\_vimrc uses plain text to provide startup specifications for the text editor gvim. This is the standalone installation for Windows, not the one the one that comes with Cygwin. However, that is just the problem context. The real issue is that I see two different versions of that file depending on whether I access it from Windows for Cygwin. The first version is from before a modification I made, and the second version is from the modification itself (adding the following two lines, the exact meanings of which aren't central to the problem): set guioptions-=m set guioptions-=T When I saved the modified file, I got a warning that the file is read-only. It isn't read-only (for the owner) according to ls -l and according to the file's Properties panel pulled up in Windows. I thought that the discrepancy must have been due to Windows 7's more complicated security (which I haven't completely figured out). I forced the save with w!, tested it by restarting gvim, and found that the settings did not take. I wondered whether the file actually contained the above two lines that I added. It turns out that it depends on how the file is accessed. If I access the file using notepad or windows-based gvim, the two added lines are not present (same thing if I use Windows's more from cmd.exe). On the other hand, if I access the file using vim or less from cygwin's bash shell, the two added lines *are* present. I initially didn't recall whether the modification was made from a Windows editor or a Cygwin editor. However, further testing indicates that it must have been via Cygwin, since the Windows-based gvim merely retorts Can't open file for writing. After googling about different versions of files on Windows 7, I found that one possible cause might be the backups that the OS makes. However, I confirmed that this particular file has no backups. This doesn't appear to be the problem. Right now, I am not sure whether this is a Windows 7 problem or a cygwin problem (or more likely, an interaction between them). I don't want to force both copies to be the same by simply editting the file using the Windows-base gvim. This hides a problem that will doubtlessly come back and cause great grief. In fact, after replicating the problem with a copy of _vimrc (Test.txt), I found that the problem is much broader than just edits to a file. I could delete Test.txt in Windows Explorer and still be able to see and edit it from Cygwin Bash. In other cases, after a failed attempt to write a modified file from Windows's gvim, the file appears empty from Cygwin's less (and can't be overwritten by a bash pipe) even though the content is clearly visible from Windows's Notepad and gvim. Thanks for any comments or suggestions for courses of action. I'm beginning to wonder if a fundamental incompatibility with Windows 7 (64-bit, in case it matters) could prevent the use of Cygwin on my machine. Mega- :( -- 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: Installing cygwin on Windows 7 prompts for Admin credentials
Greetings, Robert Jacobson! Or rename setup.exe to foo.exe. I'm both relieved and dismayed that it is so easy to bypass ... It's not THAT easy. In this regard, UAC is troubling more than helping. User with limited rights will not be able to affect system stability (except if using exploits and security holes, that M$ leave a ton). That said, the prompt is completely bogus. -- WBR, Andrey Repin (anrdae...@freemail.ru) 26.06.2011, 21:14 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: Divergent file system contents, Cygwin versus Windows 7
Am 26.06.2011 17:14 schrieb Andrew Hancock: Thanks for any comments or suggestions for courses of action. I'm beginning to wonder if a fundamental incompatibility with Windows 7 (64-bit, in case it matters) could prevent the use of Cygwin on my machine. Mega- :( It works as designed (TM). That's the Vista file virtualization in action, which is supposed to increase application compatibility in conjunction with UAC. Section File Virtualization from http://msdn.microsoft.com/en-us/library/bb756960.aspx has more on it. -- 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: Divergent file system contents, Cygwin versus Windows 7
Michael Lutz Michi_cc at gmx.net writes: Am 26.06.2011 17:14 schrieb Andrew Hancock: Thanks for any comments or suggestions for courses of action. I'm beginning to wonder if a fundamental incompatibility with Windows 7 (64-bit, in case it matters) could prevent the use of Cygwin on my machine. Mega- :( It works as designed (TM). That's the Vista file virtualization in action, which is supposed to increase application compatibility in conjunction with UAC. Section File Virtualization from http://msdn.microsoft.com/en-us/library/bb756960.aspx has more on it. Thanks, Michael. I also got a reply at http://answers.microsoft.com/en-us/windows/forum/windows_7-files/does-windows-7-do-file-caching-which-can-lead-to/181d8eca-4b59-4121-a8a9-545f465a9f61. That thread also provides a good reference to file virtualization: http://support.microsoft.com/kb/927387 . I achieved the desired effect of modifying the nonvirtualized _vimrc by clicking on Compatibility Files to go to the virtualization directory and moving it from there to the location ov the nonvirtualized _vimrc (thus overwriting it). -- 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: Divergent file system contents, Cygwin versus Windows 7
On 6/26/11 11:37 AM, Andy wrote: I achieved the desired effect of modifying the nonvirtualized _vimrc by clicking on Compatibility Files to go to the virtualization directory and moving it from there to the location ov the nonvirtualized _vimrc (thus overwriting it). I usually run with UAC virtualization turned off, and I've experienced no ill effects. You can turn off the virtualization settings by disabling the Windows Settings-Security Settings-Local Policies-Security Options-UAC: Virtualize file and registry write failures to per-user locations option. See http://technet.microsoft.com/en-us/library/dd851895.aspx That said, it's absolutely crazy that you're trying to write to a vimrc in program files! Do you edit random files in /usr to change settings under other Unixish systems? The real problem here is vim's, and it's better to not let UAC mask such problems. signature.asc Description: OpenPGP digital signature
Re: Divergent file system contents, Cygwin versus Windows 7
Daniel Colascione dan.colascione at gmail.com writes: On 6/26/11 11:37 AM, Andy wrote: I achieved the desired effect of modifying the nonvirtualized _vimrc by clicking on Compatibility Files to go to the virtualization directory and moving it from there to the location ov the nonvirtualized _vimrc (thus overwriting it). I usually run with UAC virtualization turned off, and I've experienced no ill effects. You can turn off the virtualization settings by disabling the Windows Settings-Security Settings-Local Policies-Security Options-UAC: Virtualize file and registry write failures to per-user locations option. See http://technet.microsoft.com/en-us/library/dd851895.aspx That said, it's absolutely crazy that you're trying to write to a vimrc in program files! Do you edit random files in /usr to change settings under other Unixish systems? The real problem here is vim's, and it's better to not let UAC mask such problems. That's a very interesting switch. I don't know what the best practice is yet for that switch. Virtualization can hide incompatibilities with Win 7 UAC and allow those incompatibilities to perpetuate. I'll leave the switch on for now until I see whether an explicit best practice emerges. I like the idea of separating user and system files, like in unix. However, the the vimrc file in Program Files is the default vimrc. I do in fact want to modify the default vimrc so that no matter what account launches gvim, it will inherit those settings (unless they are overridden by a local vimrc). Since I am the only user of this machine, new user accounts will only be created for experimental reasons, or to generate default account settings for snafu-recovery purposes. -- 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: Installing cygwin on Windows 7 prompts for Admin credentials
On Jun 23 15:52, Robert Jacobson wrote: Hi, I would like to let one of my users install cygwin as a normal (non-admin) account. However, when they run setup.exe, they get a UAC prompt Do you want to allow the following program from an unknown publisher to make changes to your computer? To continue, type an administrator password, and then click Yes. I'd like to let them install it, but obviously I don't want to give them admin privs. What else can I do to workaround this? Start Local Security Policy - Security Settings - Local Policies - Security Options. Disable the setting User Account Control: Detect application installations and prompt for elevation. Or rename setup.exe to foo.exe. http://msdn.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic3 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Installing cygwin on Windows 7 prompts for Admin credentials
On 6/24/2011 4:39 AM, Corinna Vinschen wrote: Or rename setup.exe to foo.exe. Thanks! I'm both relieved and dismayed that it is so easy to bypass ... -- Robert Jacobson -- 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
Installing cygwin on Windows 7 prompts for Admin credentials
Hi, I would like to let one of my users install cygwin as a normal (non-admin) account. However, when they run setup.exe, they get a UAC prompt Do you want to allow the following program from an unknown publisher to make changes to your computer? To continue, type an administrator password, and then click Yes. I'd like to let them install it, but obviously I don't want to give them admin privs. What else can I do to workaround this? -- Robert Jacobson -- 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: Installing cygwin on Windows 7 prompts for Admin credentials
I have tried to install Cygwin for Windows 7 but it failed to finish installation and stalls at 99% .No idea why but never was asked on allowing it to make changes to the computer. i am also using plain text format and hope this message go through for god sake! On Thu, Jun 23, 2011 at 3:52 PM, Robert Jacobson q7zfcr...@sneakemail.com wrote: Hi, I would like to let one of my users install cygwin as a normal (non-admin) account. However, when they run setup.exe, they get a UAC prompt Do you want to allow the following program from an unknown publisher to make changes to your computer? To continue, type an administrator password, and then click Yes. I'd like to let them install it, but obviously I don't want to give them admin privs. What else can I do to workaround this? -- Robert Jacobson -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Pining Cygwin in Windows 7?
Hi all, I just installed Cygwin on my new system, which runs Windows 7. There's a feature in Win7 similar to QuickLinks that I've been using to pin my applications to the task bar for a quick start. I'd like to do the same for Cygwin, but since it starts as batch file, all the pin function does is give me a DOS prompt. Has anyone encountered this before, and devised a fix for it? I think I can just whip up a short C program to execute bash like the batch file does, and then just pin that executable. But does anyone know of something better? Thanks in advance for any help you can provide. -- 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: Pining Cygwin in Windows 7?
On 2/27/2011 1:38 PM, Brenden Towey wrote: I just installed Cygwin on my new system, which runs Windows 7. There's a feature in Win7 similar to QuickLinks that I've been using to pin my applications to the task bar for a quick start. I'd like to do the same for Cygwin, but since it starts as batch file, all the pin function does is give me a DOS prompt. Try installing mintty, then launching C:\cygwin\bin\mintty.exe - (e.g. with the argument '-') as your pin. (I don't know much about W7, but at least you'd be starting an executable instead of a batch file). -- Chuck -- 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: Pining Cygwin in Windows 7?
On Sun, Feb 27, 2011 at 12:44 PM, Charles Wilson wrote: Try installing mintty, then launching C:\cygwin\bin\mintty.exe - (e.g. with the argument '-') as your pin. (I don't know much about W7, but at least you'd be starting an executable instead of a batch file). -- Chuck You don't need to create any special shortcut to launch it. Launching mintty from the shortcut that is added when you install it and then pinning the resultant box to the task bar works for me on Windows 7 Home Premium 64-bit SP1. -Jason -- 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: USB flash drive not showing up in Cygwin under Windows 7
* Jeffrey J. Kosowsky (Sun, 02 Jan 2011 00:32:33 -0500) My USB thumb drive does not show up in /cygdrive/ (or seemingly anywhere else for that matter). It does of course show up in the regular Windows 7 GUI in the Computer folder. This happens even if I open the cygwin window using Runas Administrator I am running Cygwin 1.7. Am I missing something obvious here? Is there something I need to do to tell Cygwin to look for a USB flash drive? Turn off UAC. Thorsten -- 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
USB flash drive not showing up in Cygwin under Windows 7
My USB thumb drive does not show up in /cygdrive/ (or seemingly anywhere else for that matter). It does of course show up in the regular Windows 7 GUI in the Computer folder. This happens even if I open the cygwin window using Runas Administrator I am running Cygwin 1.7. Am I missing something obvious here? Is there something I need to do to tell Cygwin to look for a USB flash drive? -- 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: USB flash drive not showing up in Cygwin under Windows 7
On 1/2/2011 12:32 AM, Jeffrey J. Kosowsky wrote: My USB thumb drive does not show up in /cygdrive/ (or seemingly anywhere else for that matter). It does of course show up in the regular Windows 7 GUI in the Computer folder. This happens even if I open the cygwin window using Runas Administrator I am running Cygwin 1.7. Am I missing something obvious here? Is there something I need to do to tell Cygwin to look for a USB flash drive? No. Please follow the problem reporting guidelines outlined here to report the problem: Problem reports: http://cygwin.com/problems.html -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Cron 'WRONG FILE OWNER' Problem Cygwin 1.7/Windows 7
Hi I had been happily using 'cron' on cygwin for quite a while. After updating the user password using cron-config, suddenly cron refuses to read my cron tab, putting 'WRONG FILE OWNER' in the Windows application log. Has this been seen and resolved? I have been trying for weeks now but no luck, so at this point and help would be appreciated. thanks in advance, Bruce Current version -rwxr-xr-x 1 baileyb root 5304 2010-02-15 18:14 /usr/share/doc/Cygwin/cron-4.1-59.README Running crons: 305651723056 1680? 1006 15:06:29 /usr/sbin/cron Sendmail: lrwxrwxrwx 1 baileyb por_ccusers 16 2010-12-10 08:23 /usr/sbin/sendmail - /usr/bin/cronlog Crontabs: -rw-r- 1 baileyb root 1173 2010-12-13 07:51 /var/cron/tabs/baileyb -rw-r- 1 32638 0 1173 2010-12-13 07:51 /var/cron/tabs/baileyb cron.log: -rw-r--r-- 1 baileyb None 0 2010-12-13 15:06 /var/log/cron.log cron.pid: -rw-r--r-- 1 baileyb None 5 2010-12-13 15:06 /var/run/cron.pid Crontab: # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.aXS2AsqUzu installed on Mon Dec 13 07:51:13 2010) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) # field allowed values # - -- # minute 0-59 # hour 0-23 # day of month 1-31 # month 1-12 (or names, see below) # day of week0-7 (0 or 7 is Sun, or use names) # USER=baileyb PATH=/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Bin 35 */4 * * * /usr/local/bin/cleantmp.bsh /var/log/cron.log 21 00 09 * * mon,wed,fri /usr/local/bin/loadbackuppass.bsh /var/log/cron.log 21 50 14 * * fri /usr/local/bin/backup_incr.bsh full /var/log/cron.log 21 50 14 * * mon,wed /usr/local/bin/backup_incr.bsh incr /var/log/cron.log 21 15 11 * * * /usr/bin/updatedb /var/log/cron.log 21 * * * * * env /tmp/env.txt 21 Windows Application Events log: 2010/12/13 15:06:29 [baileyb] /usr/sbin/cron: PID 3056: (CRON) STARTUP (V5.0) 2010/12/13 15:06:29 [baileyb] /usr/sbin/cron: PID 3056: (baileyb) WRONG FILE OWNER (tabs/baileyb) 2010/12/13 15:06:30 [baileyb] cron: PID 5172: `cron' service started 2010/12/13 15:07:16 [baileyb] crontab: PID 948: (baileyb) LIST (baileyb) Cygcheck: Cygwin Configuration Diagnostics Current System Time: Mon Dec 13 15:07:16 2010 Windows 7 Enterprise Ver 6.1 Build 7600 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Perl\site\bin C:\Perl\bin C:\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Program Files\GNU\GnuPG C:\Program Files\doxygen\bin Output from C:\cygwin\bin\id.exe UID: 1006(baileyb) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) 30633(por_ccusers) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'baileyb' PWD = '/tmp' CYGWIN = 'ntsec' HOME = '/home/baileyb' HOMEPATH = '\' APPDATA = 'C:\Users\baileyb\AppData\Roaming' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' HOSTNAME = 'POR-BAILEYB' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 37 Stepping 2, GenuineIntel' TERM = 'rxvt-cygwin-native' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' WINDOWID = '11895008' USERDOMAIN = 'DS' ALLUSERSPROFILE = 'C:\ProgramData' OS = 'Windows_NT' UATDATA = 'C:\Windows\system32\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' DEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection' VS90COMNTOOLS = 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\' USERNAME = 'baileyb' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' __COMPAT_LAYER = 'ElevateCreateProcess RunAsAdmin' USERPROFILE = 'C:\Users\baileyb' LANG = 'C.UTF-8' LOGONSERVER = '\\DSDC1POR' LOCALAPPDATA = 'C:\Users\baileyb\AppData\Local' PROCESSOR_ARCHITECTURE = 'x86' ProgramData = 'C:\ProgramData' COLORFGBG = '0;default;15' SHLVL = '2' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' USERDNSDOMAIN = 'DS.AD.XXX.COM' HOMEDRIVE = 'U:' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PROCESSOR_REVISION = '2502' CVS_RSH = '/bin/ssh' PRINTER = '\\plazaprint\gloria' PROGRAMFILES = 'C:\Program Files' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' HOMESHARE = '\\fileserv\users\baileyb' DISPLAY = ':0' NUMBER_OF_PROCESSORS = '4' VSEDEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection' COMPUTERNAME = 'POR-BAILEYB' COLORTERM = 'rxvt-xpm' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations\text\shell\MinEd\command-cygwin (default) = 'C:\cygwin\bin\mintty -oLocale=C -oCharset=UTF-8
Re: Cron 'WRONG FILE OWNER' Problem Cygwin 1.7/Windows 7
On 12/15/2010 4:56 PM, Bruce Bailey wrote: Hi I had been happily using 'cron' on cygwin for quite a while. After updating the user password using cron-config, suddenly cron refuses to read my cron tab, putting 'WRONG FILE OWNER' in the Windows application log. Have you stopped and restarted the cron service so that it's running with the current password for baileyb? -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Cron 'WRONG FILE OWNER' Problem Cygwin 1.7/Windows 7
At 04:56 PM 12/15/2010, Bruce Bailey wrote: Hi I had been happily using 'cron' on cygwin for quite a while. After updating the user password using cron-config, suddenly cron refuses to read my cron tab, putting 'WRONG FILE OWNER' in the Windows application log. Has this been seen and resolved? Do you have two baileyb users, one with uid 32638 and owning the crontab and another one with uid 1006 and being setuid by cron? -rw-r- 1 baileyb root 1173 2010-12-13 07:51 /var/cron/tabs/baileyb -rw-r- 1 32638 0 1173 2010-12-13 07:51 /var/cron/tabs/baileyb Output from C:\cygwin\bin\id.exe UID: 1006(baileyb) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) 30633(por_ccusers) Pierre -- 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
FW: Cron 'WRONG FILE OWNER' Problem Cygwin 1.7/Windows 7
Larry/Pierre I did indeed restart the cron service, but I appear to have TWO 'baileyb' users in /etc/passwd -- I'll pursue correcting that. I'm not sure how I did that, but it sure looks like a problem. Thanks! Bruce Date: Wed, 15 Dec 2010 17:28:31 -0500 To: bruce1...@hotmail.com From: pierre.humb...@ieee.org Subject: Re: Cron 'WRONG FILE OWNER' Problem Cygwin 1.7/Windows 7 Bruce, If the answer to my question is yes, doesn't cron-config produce a message such as Do you want the cron daemon to run as yourself? (yes/no) yes WARNING: User Compaq_Administrator appears 2 times in /etc/passwd. This may confuse the system. Edit /etc/passwd and assign unique user ids. Thanks Pierre At 04:56 PM 12/15/2010, you wrote: Hi I had been happily using 'cron' on cygwin for quite a while. After updating the user password using cron-config, suddenly cron refuses to read my cron tab, putting 'WRONG FILE OWNER' in the Windows application log. Has this been seen and resolved? I have been trying for weeks now but no luck, so at this point and help would be appreciated. thanks in advance, Bruce -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 12:49 AM, Vasya Pupkin wrote: No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: I read Andy's comment to mean that the mess of your own making is the result of you changing the permissions, not the existing permissions as left by setup.exe. You made the mess (or correction as you see it) and are now fighting with setup.exe to maintain it. drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This + sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. The + indicates that there are further permissions specified as ACLs for which the getfacl and setfacl commands should be used to view and manipulate, respectively. You would see the same behavior from ls on a Linux system which had ACL support and extra ACLs applied to a similar file or directory. There, too, chmod would not be able to modify those ACLs. What your example does not indicate is that anything unintentional happened with the application of permissions on that example directory. Nor does it indicate that the given permissions are in any way harmful to the maintenance of your system or the use of the files and directories in question. Where was that directory located? Did you create it, or did setup.exe create it? What problems do those permissions cause? Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. I'm sure the Cygwin developers would be more than willing to patch any defect surrounding the incorrect application of permissions to files which is the result of Cygwin itself or setup.exe. Unfortunately, you have not demonstrated any such erroneous behavior yet. It seems more likely that you have a small misunderstanding about how the permissions you see work and how they are represented under Cygwin. Have you read the section of the user guide which discusses permissions under Cygwin? Perhaps, you have found a genuine defect. If so, you need to provide more data so that someone else can reproduce the problem. You could start by installing another instance of Cygwin into a fresh directory (this won't affect your primary installation) and then demonstrate the specific files that have faulty permissions and explain how those permissions will lead to further problems. With luck, someone will be able to explain why things are the way you see them such that you are comfortable accepting how Cygwin does things. :-) -Jeremy -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
If you read again very carefully, you will see that I modified permissions AFTER I noticed they were messed up. Ok? In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. I was asked why I care about permissions, so I answered. Anyway, the problem is solved now, I also submitted an easy patch to setup.exe source for everyone who want to get rid of this problem as well. If I ever get into a problem with permissions again, I will try to make a proper bug report instead of just fixing permissions. On Thu, Sep 2, 2010 at 6:28 PM, Jeremy Bopp jer...@bopp.net wrote: On 9/2/2010 12:49 AM, Vasya Pupkin wrote: No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: I read Andy's comment to mean that the mess of your own making is the result of you changing the permissions, not the existing permissions as left by setup.exe. You made the mess (or correction as you see it) and are now fighting with setup.exe to maintain it. drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This + sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. The + indicates that there are further permissions specified as ACLs for which the getfacl and setfacl commands should be used to view and manipulate, respectively. You would see the same behavior from ls on a Linux system which had ACL support and extra ACLs applied to a similar file or directory. There, too, chmod would not be able to modify those ACLs. What your example does not indicate is that anything unintentional happened with the application of permissions on that example directory. Nor does it indicate that the given permissions are in any way harmful to the maintenance of your system or the use of the files and directories in question. Where was that directory located? Did you create it, or did setup.exe create it? What problems do those permissions cause? Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. I'm sure the Cygwin developers would be more than willing to patch any defect surrounding the incorrect application of permissions to files which is the result of Cygwin itself or setup.exe. Unfortunately, you have not demonstrated any such erroneous behavior yet. It seems more likely that you have a small misunderstanding about how the permissions you see work and how they are represented under Cygwin. Have you read the section of the user guide which discusses permissions under Cygwin? Perhaps, you have found a genuine defect. If so, you need to provide more data so that someone else can reproduce the problem. You could start by installing another instance of Cygwin into a fresh directory (this won't affect your primary installation) and then demonstrate the specific files that have faulty permissions and explain how those permissions will lead to further problems. With luck, someone will be able to explain why things are the way you see them such that you are comfortable accepting how Cygwin does things. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 10:05 AM, Vasya Pupkin wrote: If you read again very carefully, you will see that I modified permissions AFTER I noticed they were messed up. Ok? I tried to point out that your definition of messed up is the opposite of Andy's. To you, the default permissions provided by setup.exe are messed up. To Andy, the permissions you created are messed up. I hope that clarifies things. In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. Yes, the more I read, the more I come to believe that the disconnect here is in the definition of correct and acceptable permissions. Your definition differs from that of the Cygwin developers. It's good that your permissions changes worked for you, but it's possible that they won't work for everyone. A better description of your original problem as well as how your proposed solution addresses that problem would allow for a more productive discussion. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. I was asked why I care about permissions, so I answered. Anyway, the problem is solved now, I also submitted an easy patch to setup.exe source for everyone who want to get rid of this problem as well. If I ever get into a problem with permissions again, I will try to make a proper bug report instead of just fixing permissions. Your answer was simply an assertion that there possibly was and may still be something wrong with the permissions handling under Cygwin, but that you also haven't confirmed that recently. The details really would be helpful and likely necessary if you would like to have your patch accepted by the maintainers of setup.exe. The only other option is to independently maintain your patch and rebuild your version of setup.exe any time the upstream version changes. This won't help most users, though, because they will either not know about your patch or not care to build their own setup.exe without having any evidence of an existing problem and assurance that your change doesn't introduce other problems. If you're satisfied with your solution, so be it, but you could pretty quickly gather the necessary details for a bug report by performing a second installation of Cygwin into a new directory and reporting the flawed permissions. That could lead to the acceptance of your patch or something similar to the benefit of everyone. -Jeremy -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Thu, Sep 2, 2010 at 8:25 PM, Jeremy Bopp jer...@bopp.net wrote: Your answer was simply an assertion that there possibly was and may still be something wrong with the permissions handling under Cygwin, but that you also haven't confirmed that recently. The details really would be helpful and likely necessary if you would like to have your patch accepted by the maintainers of setup.exe. No, my patch can't be accepted as it removes permissions handling completely. It wasn't me who started the thread and I believe, my patch can be of interest for anyone else who will search for a solution for this specific problem. Anyway, I don't see how an option to switch off permissions handling by setup.exe can harm while there is similar functionality in cygwin itself. My very limited understanding of C is not enough to do this, and I never worked with GUI applications. But I will see if it can be done via command line switch and if I succeed, I will submit a proper patch. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2 September 2010 16:05, Vasya Pupkin wrote: In my case, these additional permissions were allowing everyone to modify files. Not harmful at all, indeed. I do not remember all the details, I remember these permissions were everywhere. So I just replaced everything with proper permissions and disabled acl support in cygwin. The only problem was setup.exe but now I compiled it with a modification and this last problem gone. I understand that I do not have all the details required for a bug report. And it wasn't an attempt to report a bug. Intended or not, this is a bug report, and a rather serious one at that. Any further details might be useful. When was it that you saw that problem? Still during the beta phase or after 1.7.1 was released? How did you find the problematic permissions? By looking at the security tab of the file properties? Did you confirm that users really were able to modify files they weren't supposed to? Could the offending privileges have been inherited from the directory Cygwin was installed in? Andy -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 9/2/2010 4:49 PM, Andy Koppe wrote: How did you find the problematic permissions? By looking at the security tab of the file properties? Remember that the security tab has the very bad habit of re-ordering the ACLs -- but the effect of ACLs is order dependent. Hence, just looking at the permissions of a cygwin-managed directory or file, using the security tab, can introduce a Heisenbug: there was no bug until you observed the permissions. Use getfacl/setfacl to manipulate the permissions/ACLs of cygwin-managed files. -- Chuck -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Fri, Sep 3, 2010 at 12:49 AM, Andy Koppe andy.ko...@gmail.com wrote: How did you find the problematic permissions? By looking at the security tab of the file properties? Did you confirm that users really were able to modify files they weren't supposed to? Could the offending privileges have been inherited from the directory Cygwin was installed in? If only I could remember all the details. I didn't have much time to figure out what happened. Easy solution for me was to disable acl in cygwin, which I did, and was happy until I used setup.exe and found out it destroyed my permissions. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
There we go, a proper patch. It adds two command line parameters: -f --no-acl-files -F --no-acl-dirs I could not figure if that's possible to share single variable between two source files, so I just used two variables. At least it works as intended and covers every situation. On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. Well, go ahead then. What are you waiting for? Send us a patch. cgf -- 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 filemanip.cc.diff Description: Binary data mkdir.cc.diff Description: Binary data -- 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
Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
-- Forwarded message -- From: Harie Ram hari.ra...@gmail.com Date: Tue, Aug 31, 2010 at 8:11 PM Subject: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7 To: cygwin-i...@cygwin.com Hi , I am currently packaging Cygwin 1.7 i.e. bundling all the files into an msi and installing it. The requirement is : install only the basic cygwin packages. Provide permissions to the Cygwin users so that they can install the packages that they require later. The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. I have tried editing the /etc/fstab file with the noacl value. Still its not working. The content of my /etc/fstab file is as follows: C:/cygwin/bin /usr/bin ntfs binary,auto,noacl 0 0 C:/cygwin/lib /usr/lib ntfs binary,auto,noacl 0 0 C:/cygwin /cygwin ntfs override,binary,auto,noacl 0 0 I am aware of the fact that CYGWIN=nontsec environment variable is obsolete for this version. Please help. Thanks, HRS Hi , I am currently packaging Cygwin 1.7 i.e. bundling all the files into an msi and installing it. The requirement is : install only the basic cygwin packages. Provide permissions to the Cygwin users so that they can install the packages that they require later. The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. I have tried editing the /etc/fstab file with the noacl value. Still its not working. The content of my /etc/fstab file is as follows: C:/cygwin/bin /usr/bin ntfs binary,auto,noacl 0 0 C:/cygwin/lib /usr/lib ntfs binary,auto,noacl 0 0 C:/cygwin /cygwin ntfs override,binary,auto,noacl 0 0 I am aware of the fact that CYGWIN=nontsec environment variable is obsolete for this version. Please help. Thanks, HRS -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
I am facing similar issue and this is actually why I stopped using Cygwin. There is no way to tell setup.exe to stop destroying permissions. And noone seem to care about it. On Wed, Sep 1, 2010 at 12:00 PM, Harie Ram hari.ra...@gmail.com wrote: -- Forwarded message -- From: Harie Ram hari.ra...@gmail.com Date: Tue, Aug 31, 2010 at 8:11 PM Subject: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7 To: cygwin-i...@cygwin.com Hi , I am currently packaging Cygwin 1.7 i.e. bundling all the files into an msi and installing it. The requirement is : install only the basic cygwin packages. Provide permissions to the Cygwin users so that they can install the packages that they require later. The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. I have tried editing the /etc/fstab file with the noacl value. Still its not working. The content of my /etc/fstab file is as follows: C:/cygwin/bin /usr/bin ntfs binary,auto,noacl 0 0 C:/cygwin/lib /usr/lib ntfs binary,auto,noacl 0 0 C:/cygwin /cygwin ntfs override,binary,auto,noacl 0 0 I am aware of the fact that CYGWIN=nontsec environment variable is obsolete for this version. Please help. Thanks, HRS -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also be configured to not touch ACL's at all, but setup program ignores that and messes up permissions every time something is installed/updated. On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell rcampbell-cyg...@dragonwaveinc.com wrote: On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Do creating any entries in /etc/passwd or /etc/group or /etc/fstab files can overcome this... Thanks On Wed, Sep 1, 2010 at 7:21 PM, Vasya Pupkin cyg...@bsrealm.net wrote: Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also be configured to not touch ACL's at all, but setup program ignores that and messes up permissions every time something is installed/updated. On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell rcampbell-cyg...@dragonwaveinc.com wrote: On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Nothing can overcome thins until setup.exe is modified to support noacl option in /etc/fstab or get a similar comman line parameter or even a checkbox. On Wed, Sep 1, 2010 at 6:00 PM, Harie Ram hari.ra...@gmail.com wrote: Do creating any entries in /etc/passwd or /etc/group or /etc/fstab files can overcome this... Thanks On Wed, Sep 1, 2010 at 7:21 PM, Vasya Pupkin cyg...@bsrealm.net wrote: Cygwin uses NTFS ACLs to imitate POSIX style permissions. It can also be configured to not touch ACL's at all, but setup program ignores that and messes up permissions every time something is installed/updated. On Wed, Sep 1, 2010 at 4:49 PM, Rolf Campbell rcampbell-cyg...@dragonwaveinc.com wrote: On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 1 September 2010 09:00, Harie Ram wrote: I am currently packaging Cygwin 1.7 i.e. bundling all the files into an msi and installing it. The requirement is : install only the basic cygwin packages. Provide permissions to the Cygwin users so that they can install the packages that they require later. The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. Giving users the right to change a global Cygwin install doesn't sound like a terribly good idea. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. Administrators can grant themselves the right to access those folders though. Andy -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 1 September 2010 15:18, Vasya Pupkin wrote: Do creating any entries in /etc/passwd or /etc/group or /etc/fstab files can overcome this... Nothing can overcome thins until setup.exe is modified to support noacl option in /etc/fstab or get a similar comman line parameter or even a checkbox. Reading /etc/fstab wouldn't work for the initial install. All these possibilities require a substantial amount of (voluntary) work, yet so far the only reason you've given for it was that you don't like how cygwin works with NTFS permissions and therefore it is disabled through /etc/fstab. It shouldn't surprise you that that doesn't put it high on anyone's list of priorities. So why do you care about permissions on files that come with setup.exe packages? Setup.exe won't touch /home or anything outside the Cygwin install. Andy -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. I started to worry about it because cygwin failed so much with permissions, having both cygwin-specific and inherited ones (copied) at the same time, resulting in complete mess. A non-privileged user could modify cygwin configuration files in /etc and it was not possible to do something about it. That is when I decided to control permissions myself, but cygwin setup overwrites permissions on every install, including files in /etc, messing up everything. On Thu, Sep 2, 2010 at 12:18 AM, Andy Koppe andy.ko...@gmail.com wrote: On 1 September 2010 15:18, Vasya Pupkin wrote: Do creating any entries in /etc/passwd or /etc/group or /etc/fstab files can overcome this... Nothing can overcome thins until setup.exe is modified to support noacl option in /etc/fstab or get a similar comman line parameter or even a checkbox. Reading /etc/fstab wouldn't work for the initial install. All these possibilities require a substantial amount of (voluntary) work, yet so far the only reason you've given for it was that you don't like how cygwin works with NTFS permissions and therefore it is disabled through /etc/fstab. It shouldn't surprise you that that doesn't put it high on anyone's list of priorities. So why do you care about permissions on files that come with setup.exe packages? Setup.exe won't touch /home or anything outside the Cygwin install. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2 September 2010 03:08, Vasya Pupkin wrote: Because I prefer to keep things under control Oh $DEITY. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. I started to worry about it because cygwin failed so much with permissions, having both cygwin-specific and inherited ones (copied) at the same time, resulting in complete mess. That appears to be a mess of your own making. Otherwise, concrete bug reports please. The OP's complaint here was that permissions aren't inherited, so I've got no idea what you're on about. A non-privileged user could modify cygwin configuration files in /etc and it was not possible to do something about it. Well, I don't know what you did, but I install Cygwin as administrator and work as an ordinary user, and no, I can't modify anything in /etc. And that's no accident of course, because a lot of work has gone into mapping POSIX permissions to NTFS permissions in a sensible way. Andy ps: Please don't top-post. http://www.cygwin.com/acronyms/#TOFU -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. Well, go ahead then. What are you waiting for? Send us a patch. cgf -- 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: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
Will do as soon as I get this thing to at least compile. Actually, since there is no abstract layer for nt_wfopen(), all calls to this function have to be modified. Alternatively, the function can be modified to ignore perms parameter and alternative version of setup.exe can be compiled then. That is the way I chose, but there is some problem in another file that I cannot fix myself. You can see my previous message about that. Regardless, this is the simple patch: === --- filemanip.cc2010-03-01 18:18:39.0 +0300 +++ filemanip.cc.new2010-09-02 09:33:05.094182900 +0400 @@ -433,8 +433,10 @@ IO_STATUS_BLOCK io; UNICODE_STRING uname; OBJECT_ATTRIBUTES attr; + /* SECURITY_DESCRIPTOR sd; acl_t acl; + */ const char *c; ULONG access, disp; int oflags = 0; @@ -489,11 +491,14 @@ PWCHAR wname = (PWCHAR) wpath; wname[1] = L'?'; RtlInitUnicodeString (uname, wname); + /* InitializeObjectAttributes (attr, uname, OBJ_CASE_INSENSITIVE, NULL, disp == FILE_OPEN || perms == 0 ? NULL : nt_sec.GetPosixPerms (, NULL, NULL, perms, sd, acl)); + */ + InitializeObjectAttributes (attr, uname, OBJ_CASE_INSENSITIVE, NULL, NULL); status = NtCreateFile (h, access | SYNCHRONIZE, attr, io, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_VALID_FLAGS, disp, FILE_OPEN_FOR_BACKUP_INTENT === Instead of commenting code, defines can be used to allow choosing required behaviour at compile time. On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote: Because I prefer to keep things under control. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. Well, go ahead then. What are you waiting for? Send us a patch. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
No, it wasn't a mess of my own making. I did not ever touch permissions, and it was a clean install. I don't know where these permissions came from, but ls -l displayed something like that for most files: drwxr-xr-x+ 1 user group 0 2010-09-02 09:32 tests This + sign after permissions string indicated non-cygwin permissions which was impossible to remove using cygwin's chmod. And since permissions are not inherited, it was not possible to mass remove them using windows either. So, I just removed all permissions and forced their inheritance. That solved all problems, until I updated installation using setup.exe. Believe me or not, but I really did not touch any permissions until I noticed that strange behaviour. And I am the only administrator. Machine is not a part of any domains. So, unless it's a kind of black magic, there was (and maybe still is) some issue with permissions in cygwin. That is why I don't want to use them. On Thu, Sep 2, 2010 at 9:10 AM, Andy Koppe andy.ko...@gmail.com wrote: On 2 September 2010 03:08, Vasya Pupkin wrote: Because I prefer to keep things under control Oh $DEITY. And I don't think it will require a huge amount of work to disable working with permissions in setup.exe with command line switch. I started to worry about it because cygwin failed so much with permissions, having both cygwin-specific and inherited ones (copied) at the same time, resulting in complete mess. That appears to be a mess of your own making. Otherwise, concrete bug reports please. The OP's complaint here was that permissions aren't inherited, so I've got no idea what you're on about. A non-privileged user could modify cygwin configuration files in /etc and it was not possible to do something about it. Well, I don't know what you did, but I install Cygwin as administrator and work as an ordinary user, and no, I can't modify anything in /etc. And that's no accident of course, because a lot of work has gone into mapping POSIX permissions to NTFS permissions in a sensible way. Andy ps: Please don't top-post. http://www.cygwin.com/acronyms/#TOFU -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin for windows 7
Hello, I just downloaded and installed the new cygwin for windows 1.7.7-1. I am having trouble issuing basic ls commands against network drives. For example,after I NET USE to a network drive and cd to it (I.e. Cd /cygdrive/z/test) and then issue the ls command, I get invalid argument. I have never seen this on xp or vista, only win 7. Is this a known problem by any chance? Thank you! Charlie Bryant Binghamton, ny charl...@stny.rr.com Sent from my Verizon Wireless BlackBerry -- 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 for windows 7
On 8/31/2010 6:31 PM, charl...@stny.rr.com wrote: Hello, I just downloaded and installed the new cygwin for windows 1.7.7-1. I am having trouble issuing basic ls commands against network drives. For example,after I NET USE to a network drive and cd to it (I.e. Cd /cygdrive/z/test) and then issue the ls command, I get invalid argument. I have never seen this on xp or vista, only win 7. Is this a known problem by any chance? Thank you! No, this is not a known problem and certainly not a common one. Please submit a problem report as described by the link below if you continue to have problems. Problem reports: http://cygwin.com/problems.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Moses with Cygwin on Windows 7
I don't know if this might interest others, but I have found a thread explaining the UAC problem at http://social.answers.microsoft.com/Forums/en-US/vistasecurity/thread/67bfc4 b5-faff-4de4-be48-f395bf1c519d. There is an unofficial third-party software available from http://www.itknowledge24.com/ to create a white list so that specific programs can be exempted from UAC prompts. We don't have a computer with Windows 7 yet, so can't test it out, but I like the idea. Llio -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Eliot Moss Sent: 08 August 2010 00:34 To: cbs...@bangor.ac.uk Cc: l...@testun.co.uk; cygwin@cygwin.com Subject: Re: Moses with Cygwin on Windows 7 On 8/7/2010 5:23 PM, cbs...@bangor.ac.uk wrote: many thanks for your reply. On why we need cygwin: the language model we use is IRSTLM. The native windows build of Moses does not currently use IRSTLM LMs. I know next to nothing about Moses, so I'll just trust you on this one! I have been reading up a bit about debasing DLLs, and I gather from http://www.codeproject.com/KB/DLL/RebaseDll.aspx that the purpose is to avoid either two or more DLLs using the same preferred base addresses, or the overheads of relocation. However, on http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bac7e300-f3df -4087-9c4b-847880d625ad, it is suggested that from Vista onwards, it is better to leave this to the operating systems's ASLR (Address space layout randomization) in order to help defeat a ?return-to-libc? attack. Do you agree with this? If it is still necessary to do a rebase, what does your script do that rebaseall doesn't? The problem is that the address space randomization interferes with how cygwin support fork(). Suppose a parent process maps library A at address X, but does not map library B at all. Then suppose a forked process is not yet using library A, and ends up mapping library B at an address that overlaps X. Then the child reaches a point where it needs to use library A. The implementation of cygwin requires that if a parent and child use the same library, it must be at the same address. Therefore the child's mapping attempt will block. That gives a sense of the scenario. That may not be the exact case, but it's like that. Basically, we need to guarantee that all cygwin dlls map to different preferred places. Yes, this defeats the OS attempt to defeat a security attack. My script finds and rebases every dll file that cygwin 'find' can locate, while rebaseall only does certain directories. For me, the difference lies in (at least) some perl-related dlls that are not where rebaseall looks. Another important thing is that the distance between preferred locations needs to be a little bigger than the default for rebase, on Vista (and Windows 7). This is an obscure thing that Corinna found a while back and took me quite a while to locate in old email threads, but before I set that parameter, rebasing did not work right for me and after adding that it did. Maybe they have changed the default by now, but I don't think so. Re UAC prompts: this does look annoying but corporate security regulations may prevent us from turning it off completely. Is there some way to turn it off for individual programs without using third-party software? That lies outside my expertise. I just turned it off. Best wishes -- 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 -- 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: Moses with Cygwin on Windows 7
Dear Eliot, your script does indeed sound much better. Is it available to share? Many thanks for sharing your insights in any case. Best regards, Llio Humphreys Quoting Eliot Moss m...@cs.umass.edu: On 8/7/2010 5:23 PM, cbs...@bangor.ac.uk wrote: many thanks for your reply. On why we need cygwin: the language model we use is IRSTLM. The native windows build of Moses does not currently use IRSTLM LMs. I know next to nothing about Moses, so I'll just trust you on this one! I have been reading up a bit about debasing DLLs, and I gather from http://www.codeproject.com/KB/DLL/RebaseDll.aspx that the purpose is to avoid either two or more DLLs using the same preferred base addresses, or the overheads of relocation. However, on http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bac7e300-f3df-4087-9c4b-847880d625ad, it is suggested that from Vista onwards, it is better to leave this to the operating systems's ASLR (Address space layout randomization) in order to help defeat a ?return-to-libc? attack. Do you agree with this? If it is still necessary to do a rebase, what does your script do that rebaseall doesn't? The problem is that the address space randomization interferes with how cygwin support fork(). Suppose a parent process maps library A at address X, but does not map library B at all. Then suppose a forked process is not yet using library A, and ends up mapping library B at an address that overlaps X. Then the child reaches a point where it needs to use library A. The implementation of cygwin requires that if a parent and child use the same library, it must be at the same address. Therefore the child's mapping attempt will block. That gives a sense of the scenario. That may not be the exact case, but it's like that. Basically, we need to guarantee that all cygwin dlls map to different preferred places. Yes, this defeats the OS attempt to defeat a security attack. My script finds and rebases every dll file that cygwin 'find' can locate, while rebaseall only does certain directories. For me, the difference lies in (at least) some perl-related dlls that are not where rebaseall looks. Another important thing is that the distance between preferred locations needs to be a little bigger than the default for rebase, on Vista (and Windows 7). This is an obscure thing that Corinna found a while back and took me quite a while to locate in old email threads, but before I set that parameter, rebasing did not work right for me and after adding that it did. Maybe they have changed the default by now, but I don't think so. Re UAC prompts: this does look annoying but corporate security regulations may prevent us from turning it off completely. Is there some way to turn it off for individual programs without using third-party software? That lies outside my expertise. I just turned it off. Best wishes -- Eliot Moss This message was sent using IMP, the Internet Messaging Program. -- 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: Moses with Cygwin on Windows 7
Dear Morgan, thanks for the tip. Can you turn it off for only some recognised programs? It does not mention this option in Microsoft's online Guided Help (http://support.microsoft.com/kb/975788). Unfortunately, I don't have Windows 7 yet so I can't test it myself. Thanks, Llio Humphreys Quoting Morgan Gangwere 0.fracta...@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/2010 05:33 PM, Eliot Moss wrote: [snip] Windows 7 has a setting /just/ below the default which turns off the Secure Desktop (Pet name for UAC prompts). If you have some amount of administrator access, you can probably disable them. - -- Morgan Gangwere 0 dotpunct fractalus atpunct gmail dotpunct com http://sonof.bandit.name/ あなたのお母さんは、ハムスターとあなたの父エルダーベリーのワカサギでした - - A frenchman. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMXiwXAAoJEEURiCSotvJDFBsP/13kN+WbgQNzw03Jxp6w3XAc P6ailneZS5s03/wO/OdnQJiQ7B5iKAlZEKp9qZ4wcLUDaBpQxIGbVrT0umRMB/r2 osMEY8TErQ/Vlro9AknRi2BvSPe1iit0Lm7jQhRPIMnnraYwzziKJWwDUuSXTREE cj5p9sWgyzvLmtTphVm1kDF94csRBkk9qQI4WLooODGkJeDMP5oFyKRX1mzNYV62 M9QZSr8/QWmXQs9lT3F2bkLRJGBrmUyfoLayNJ4+1BnNl7FfGHGQc0UqpqhHD8sD DvbXe3b7y7LPjb/dTGqGj4P3AuCZxNgtrYOuFfP4v/MZoyhj41SwjifBBFDKin97 u3sgVUXRJuSbNnzNIOPL5dk6U8nb2zo4enNzqdBNi4XfmJsidlAYhjWgGWCbfkRU 6uuJA4hAIrf/07Co/oG7q9jI7mueEIGTvxqguR67cNw+aRrCLWyNsLBOTCOUfRY3 TOjG5WBdO3MTO819V/KJdlpJ46vn37atvnvN7IELy/dWkpR7dLzBuinHDU1+V36g gUDtHNNC/Bv/Yb/c+Qp4umG8aeqRA+scLGToPdc1+bpV9MEk7ps3yfYK4xrmsb8b yCY6UNtqVdQlmCeVNV0CTjGtkdcTiJbfo8glHKUcBI6vYqCmTnp5Mw3qrBgtHeiB 92ieQKVSh9r6cg4M2hGR =K8NM -END PGP SIGNATURE- -- 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 This message was sent using IMP, the Internet Messaging Program. -- 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: Moses with Cygwin on Windows 7
Dear Eliot, many thanks for your reply. On why we need cygwin: the language model we use is IRSTLM. The native windows build of Moses does not currently use IRSTLM LMs. I have been reading up a bit about debasing DLLs, and I gather from http://www.codeproject.com/KB/DLL/RebaseDll.aspx that the purpose is to avoid either two or more DLLs using the same preferred base addresses, or the overheads of relocation. However, on http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bac7e300-f3df-4087-9c4b-847880d625ad, it is suggested that from Vista onwards, it is better to leave this to the operating systems's ASLR (Address space layout randomization) in order to help defeat a ?return-to-libc? attack. Do you agree with this? If it is still necessary to do a rebase, what does your script do that rebaseall doesn't? Re UAC prompts: this does look annoying but corporate security regulations may prevent us from turning it off completely. Is there some way to turn it off for individual programs without using third-party software? Thank you, Llio Humphreys Quoting Eliot Moss m...@cs.umass.edu: Cygwin under Windows 7 works fine for me. The things I noticed were: - It was helpful to some things, especially perl and things built from it, to rebase all the dlls. I have a script for that, though rebaseall may do it for you. - Since I am just a single user, etc., I disable the Windows Vista/7 UAC controls so that more things run without annoying popups to ask permission (and some things just won't run without further fiddling if UAC is on). I think people have resolved UAC issues with further work, but it seems to be a topic that comes up from time to time. That is, for sophisticated things it can be tricky to get them going with UAC on. A quick glance at Moses suggests that it can just be done under regular Windows using Visual Studio, so why cygwin at all? -- Eliot Moss This message was sent using IMP, the Internet Messaging Program. -- 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: Moses with Cygwin on Windows 7
On 8/7/2010 5:23 PM, cbs...@bangor.ac.uk wrote: many thanks for your reply. On why we need cygwin: the language model we use is IRSTLM. The native windows build of Moses does not currently use IRSTLM LMs. I know next to nothing about Moses, so I'll just trust you on this one! I have been reading up a bit about debasing DLLs, and I gather from http://www.codeproject.com/KB/DLL/RebaseDll.aspx that the purpose is to avoid either two or more DLLs using the same preferred base addresses, or the overheads of relocation. However, on http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bac7e300-f3df-4087-9c4b-847880d625ad, it is suggested that from Vista onwards, it is better to leave this to the operating systems's ASLR (Address space layout randomization) in order to help defeat a ?return-to-libc? attack. Do you agree with this? If it is still necessary to do a rebase, what does your script do that rebaseall doesn't? The problem is that the address space randomization interferes with how cygwin support fork(). Suppose a parent process maps library A at address X, but does not map library B at all. Then suppose a forked process is not yet using library A, and ends up mapping library B at an address that overlaps X. Then the child reaches a point where it needs to use library A. The implementation of cygwin requires that if a parent and child use the same library, it must be at the same address. Therefore the child's mapping attempt will block. That gives a sense of the scenario. That may not be the exact case, but it's like that. Basically, we need to guarantee that all cygwin dlls map to different preferred places. Yes, this defeats the OS attempt to defeat a security attack. My script finds and rebases every dll file that cygwin 'find' can locate, while rebaseall only does certain directories. For me, the difference lies in (at least) some perl-related dlls that are not where rebaseall looks. Another important thing is that the distance between preferred locations needs to be a little bigger than the default for rebase, on Vista (and Windows 7). This is an obscure thing that Corinna found a while back and took me quite a while to locate in old email threads, but before I set that parameter, rebasing did not work right for me and after adding that it did. Maybe they have changed the default by now, but I don't think so. Re UAC prompts: this does look annoying but corporate security regulations may prevent us from turning it off completely. Is there some way to turn it off for individual programs without using third-party software? That lies outside my expertise. I just turned it off. Best wishes -- 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: Moses with Cygwin on Windows 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/2010 05:33 PM, Eliot Moss wrote: [snip] Windows 7 has a setting /just/ below the default which turns off the Secure Desktop (Pet name for UAC prompts). If you have some amount of administrator access, you can probably disable them. - -- Morgan Gangwere 0 dotpunct fractalus atpunct gmail dotpunct com http://sonof.bandit.name/ あなたのお母さんは、ハムスターとあなたの父エルダーベリーのワカサギでした - - A frenchman. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMXiwXAAoJEEURiCSotvJDFBsP/13kN+WbgQNzw03Jxp6w3XAc P6ailneZS5s03/wO/OdnQJiQ7B5iKAlZEKp9qZ4wcLUDaBpQxIGbVrT0umRMB/r2 osMEY8TErQ/Vlro9AknRi2BvSPe1iit0Lm7jQhRPIMnnraYwzziKJWwDUuSXTREE cj5p9sWgyzvLmtTphVm1kDF94csRBkk9qQI4WLooODGkJeDMP5oFyKRX1mzNYV62 M9QZSr8/QWmXQs9lT3F2bkLRJGBrmUyfoLayNJ4+1BnNl7FfGHGQc0UqpqhHD8sD DvbXe3b7y7LPjb/dTGqGj4P3AuCZxNgtrYOuFfP4v/MZoyhj41SwjifBBFDKin97 u3sgVUXRJuSbNnzNIOPL5dk6U8nb2zo4enNzqdBNi4XfmJsidlAYhjWgGWCbfkRU 6uuJA4hAIrf/07Co/oG7q9jI7mueEIGTvxqguR67cNw+aRrCLWyNsLBOTCOUfRY3 TOjG5WBdO3MTO819V/KJdlpJ46vn37atvnvN7IELy/dWkpR7dLzBuinHDU1+V36g gUDtHNNC/Bv/Yb/c+Qp4umG8aeqRA+scLGToPdc1+bpV9MEk7ps3yfYK4xrmsb8b yCY6UNtqVdQlmCeVNV0CTjGtkdcTiJbfo8glHKUcBI6vYqCmTnp5Mw3qrBgtHeiB 92ieQKVSh9r6cg4M2hGR =K8NM -END PGP SIGNATURE- -- 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
Moses with Cygwin on Windows 7
Dear all, We wish to install the Moses SMT system (http://www.statmt.org/moses/) on a Windows system. It requires an Unix-like environment, and we have successfully used Cygwin (http://www.cygwin.com/) with Moses on Windows XP. We are now considering running it on a Windows 7 system. If you have experiences of using Cygwin, and Moses in particular, on a Windows 7 system, I should be grateful if you could advise on any problems, solutions, or whether in fact the installation and performance is more or less the same as on Windows XP. Many thanks, Llio Humphreys Testun Cyf -- 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
Cygwin 1.7 Windows 7/2008 Public key intermittent problem
Hi, I have about 8 machines experiencing problems while trying to use passwordless public key authentication, via passwd -R. Happening on W7, w2k8, x86 x64 sshd running on all as a domain user, with the correct local security policy changes made, and /var/empty owner by sshd user etc. pub key auth always works for the user sshd is been run as, but not any other user - connection closed by... error - windows event log does show sshd pid xxx fatal initgroups permission denied error If I reboot any of the above, generally passwordless pub key auth doesn't work - if I then rdp to windows machine, login as another user, log out - I can then ssh using keys to that machine as the user I RDP'd as - until it gets rebooted again. And then - after several more reboots - without any changes been made on the machines - I can use keys to login to the machine as any user successfully - until it gets rebooted and reverts to the usual problem I have tried installing cyglsa - but after installing and rebooting - I don't notice any difference - although I'm unsure if there is something else needed for cyglsa to function or is adding the users to the passwd/groups sufficient? Thanks for any suggestions - the fact that it intermittently works is baffling me Cheers Shane -- 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
