RE: Performance Issues due to Anti-Virus software.
Graham, If you insist that each developer runs AV software on it's development platform, you could consider setting up a separate box (without antivirus software) with ssh access for performing your builds. Throw in a few network shares, and a smart home directory mapping, and the developers will never know where they are compiling. Seriously, aren't your developers local administrators ? In that case, they could easily disable the AV. Good luck, Dan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Graham Harrison Sent: Monday, September 23, 2002 5:48 PM To: [EMAIL PROTECTED] Subject: Performance Issues due to Anti-Virus software. Hi, I support about 15 developers who use cgywin and PRC-Tools to develop for PalmOS. While migrating from cygnus version B20 to the latest version of cygwin (and then PRC-Tools) we have seen a drastic performance drop. Some may think that I'm over stating the problem, but a file which used to compile in under a second now take 6 seconds. Multiply this up by the number of files in a project, and then by the number of developers I support and you can see my point. These guys are going to kill me if I can't get it sorted!! The problem seems to be with Norton Anti-Virus. We mainly use Corp. edition, but I've tried an OEM version of 2002 and that does the same. Given that it is Corp. edition this gives me an issue or 2 over the norm: 1) the developers can't turn it off themselves so I'd have to do it and turn it on afterwards. (This is not happening!) 2) There isn't that much which can be tweaked. >From my reading on the web, I believe the problem is to do with memory mapped files. Can anyone suggest the best things to tweak to stop Norton and Cygwin from clashing with each other? Thanks. -- Graham Harrison Astraware Ltd. http://www.astraware.com. _ This message has been checked for all known viruses by the MessageLabs Virus Control Centre. Service supplied by Internet Central http://www.internet-central.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[OT] RE: Performance Issues due to Anti-Virus software.
dan > Seriously, aren't your developers local administrators ? In that case, they dan > could easily disable the AV. Igor >I'm of half a mind to set up an ssh server just to be able to su to local Igor >system and kill it. But for now I live with it. Igor, Try installing the PSTOOLS package from http://www.sysinternals.com/ntw2k/freeware/pstools.shtml. PSKILL (part of pstools) will kill virtually any process, including LocalSystem processes, given enough (local administrator) rights. Of course you can also try stopping the service in the ControlPanel (Administrative Tools|Services, right click on NAV). Here's where you would restart it. Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cscript errors out from daemon
Brandon, I don't see the problem on my w2k system : ~$ssh dan@localhost . Fanfare!!! You are successfully logged in to this server!!! ~$cscript.exe Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. Usage: CScript scriptname.extension [option...] [arguments...] Options: [] As to debugging your problem, I suggest: 1) login via telnet/ssh and type: which cscript This is WINNT/system32/cscript on my system. 2) try getting a dump of the crashed CSCRIPT. Run/Install Dr Watson as default debugger, and instruct it to create a dumpfile: c:\> drwtsn32 -i Send me a zipped version of the dump file, or try to debug it yourself using windbg from the free Microsoft "Debugging Tools for Windows" Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 25, 2002 5:55 PM To: [EMAIL PROTECTED] Subject: cscript errors out from daemon win2k cygwin 1.3.12-2 (See attached file: cygcheck.out) I am trying to run a bash script than in turn calls a vbscript from cron using cscript.exe. I get a dialog box displaying an error about cscript not being able to initialize. Application popup: cscript.exe - Application Error : The application failed to initialize properly (0xc005). Click on OK to terminate the application. I have also noticed that I cannot run cscript after logging in via telnet or ssh. I am assuming that cygwin has a problem of running cscript from within a daemon? Is there any solution to be able to run cscript from cron, ssh, telnet, etc? Thank you, Brandon Saxe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[Proposal] Moving user mount information to HKLM
Problem:
The mount -u command fails if a domain user's registry hive is not
downloaded from the domain controller and no local hive cache exists.
Solution:
Change cygwin1.dll/mount to
1. store mount information under HKLM/CYGWIN/MOUNTS/{USER-SID}, or
2. let mount succeed without persisting the mount info, by updating the
in-memory data structures and maybe issuing a warning about the missing user
hive.
I can submit patches for either solutions if needed. Solution 1 is more
intrusive since it changes the way existing user mounts are stored.
As an aside, this seems to be the solution used by SFU30 to store user
specific mounts/other info.
3. Mounting all mounts as system is not an option since there's a limit of
the amount of mounts.
Background:
We set up a Windows compile server for 20-30 developers logging in with
their domain user credentials via ssh with password. Since no domain user
has ever interactively logged in, no registry hive exists for the
authenticated user, and the mount code in cygwin1.dll will return an error
when trying to mount a user partition.
We're only interested in a temporary mount of /home/$USER for the duration
of the login session, and would appreciate being able to do so.
Our current workaround involves symlinks, but this creates problems since
`pwd` != /bin/pwd:
dan~>ssh server_without_my_hive
Password:...
[Fanfare]
# /etc/profile runs "net use H: "
# and creates a link /home/dan.lnk -> /cygdrive/h
dan~> pwd
/home/dan
dan~> /bin/pwd
/cygdrive/h
We've had to modify lots of scripts to work around this issue, and it would
certainly be nice not to have to.
Thanks,
Dan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: [Proposal] Moving user mount information to HKLM
> On the user mount in HKLM idea, it's a no-goer. Normal users don't > have write access to most of HKLM, on any partly-secure install > of NT (which is where the original posters issue arose). I may be wrong, but couldn't setup, or whoever creates the original HKLM/../cygwin key, set up the security attributes such that any authenticated user may write there ? > Secondly, there is a much more straightforward solution > for the poster: > use something like > mount $USERPROFILE$CYGHOME /home/$USER You mean creating permanent system mounts while running as administrator. We tried that, and hit some upper mount limit in cygwin1.dll. Try it yourself: ~>for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26; do mount h: /home/user$i; done Dan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [Proposal] Moving user mount information to HKLM
Robert, Your solution only works if the users are local administrators, as a domain user has no rights to HKLM (and hence to create a system mount). In our case, giving all users local administrator rights is an acceptable solution, but we're still left with a maximum of 25-30 simultaneous users. But we'll go with it while waiting for a better mount. Thanks, Dan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins Sent: Friday, September 27, 2002 4:28 PM To: Dan Vasaru Cc: [EMAIL PROTECTED] Subject: RE: [Proposal] Moving user mount information to HKLM On Sat, 2002-09-28 at 00:19, Dan Vasaru wrote: > > > On the user mount in HKLM idea, it's a no-goer. Normal users don't > > have write access to most of HKLM, on any partly-secure install > > of NT (which is where the original posters issue arose). > > I may be wrong, but couldn't setup, or whoever creates the original > HKLM/../cygwin key, set up the security attributes such that any > authenticated user may write there ? > > > Secondly, there is a much more straightforward solution > > for the poster: > > use something like > > mount $USERPROFILE$CYGHOME /home/$USER > > You mean creating permanent system mounts while running as administrator. We > tried that, and hit some upper mount limit in cygwin1.dll. Try it yourself: > > ~>for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 > 26; do mount h: /home/user$i; done Yes, it's limited to 30. See shared_info.h in the source. This affects BOTH user and system mounts. As a workaround you can hook the exiting of the login shell to unmount the path when you're finished. Hope that helps, Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [Proposal] Moving user mount information to HKLM
Robert,
>FWIW the HKLM user mounts would have the same security
>ramification (which is why it's not a generically viable solution).
True, but one could fine-tune access rights to "HKLM/Software/Cygwin" such
that:
1) All users have "Create subkey" permission in "HKLM/./Cygwin/Users".
2) All user specific information goes under a "Cygwin/Users/{SID}" subkey.
In addition to the default rights for local admin etc, full access must be
granted to {SID}.
This would ensure that whoever is authorized to login would be able to
execute mount commands. Note that all keys down to "Users" need to be opened
for READ access only, otherwise RegOpenKey will fail with permission denied.
On another note, how about adding a flag to "mount" telling it that the
mount is NOT to be persisted, in a similar fashion to the "net use
/persistent:no" command ? This would bypass the need to write to the
registry and unmount on exit.
Thanks again,
Dan.
PS. For the archives:
Problem:
The mount -u command fails if a domain user's registry hive is not
downloaded from the domain controller and no local hive cache exists.
Current workaround:
Our best workaround is to give all potential users FullControl permissions
to the "HKLM/Software" key, and mount everything as a system mount. The
security risks are that any user can modify/change/delete all registry
information under HKLM/Software.
There's a limit of about 25 mounts that can be created this way before
hitting a built-in limit of maximum 30 mount points per system+user.
Restricting write access to the "HKLM.../cygwin/mounts v2" subkey will still
result in a "Permission denied", since cygwin 1.3.12-2 tries to open all
HKLM keys (down to "HKLM/Software/mounts v2") with write access.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: CR/NL problem with cpp.exe
Nick, please refer to:
"How is the DOS/Unix CR/LF thing handled?" in the cygwin faq:
http://cygwin.com/faq/faq_4.html#SEC72
Also, read the documentation for the "mount" utility and the CYGWIN
environment variable setting.
If you want to make sure that the input to your "cpp" is translated no
matter the file access mode (which depends on the mount mode for files and
CYGWIN variable for pipes), I believe you need to make sure that the input
is set to text mode:
- when opening a file, add the text mode to the open calls:
o fopen(..., "rt")
o open(..., O_. | O_TEXT)
- when reading text from stdin:
o setmode (0, O_TEXT) // 0 is the file descriptor for stdin
.
Dan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Kris Warkentin
Sent: Tuesday, October 01, 2002 8:47 PM
To: [EMAIL PROTECTED]
Subject: Re: CR/NL problem with cpp.exe
> printf("This is a long string across\
> multiple lines");
>
> or a backslashified #define is being concatenated. Now, if I use the
Cygwin
> cpp.exe, I get the following (expected) behaviour:
Correction: I meant NOT being concatenated.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: CR/NL problem with cpp.exe
Kris, I am no authority on the matter, but I believe most Cygwin/Win32 ports of "text-based" utilities deal with CRLF/LF by setting the O_TEXT flag and letting the (C) runtime translate the line endings for them. Instead of adjusting the file input mode, please note that you may want to adjust your preprocessor lexer to accept both styles of line endings. What happens the day you will want to port your CPP to a true Unix, and will get a DOS file as an input ? Unix will blissfully ignore the O_TEXT flag in open() calls, and you'll have CR on your input pipe. GREP is an example of a utility that *doesn't* use O_TEXT, and still handles all styles of line terminations gracefully. At least in principle. Dan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kris Warkentin Sent: Tuesday, October 01, 2002 10:26 PM To: Dan Vasaru; [EMAIL PROTECTED] Subject: Re: CR/NL problem with cpp.exe I'm actually quite certain that what you wrote would help. The issue is that cccp.c (the gcc preprocessor) does not do that and, as near as I can tell from the FAQ, shouldn't need to. That, however, is where I might be wrong. I'm wondering if the cpp shipped with Cygwin has been patched so that it does explicitly open files as text. If that's the case, then that might explain why I'm seeing different behaviour. Aha! I just copied dosfile.c to a text mode partition and it works with our preprocessor. That implies that there must be some buggery in the Cygwin version of cpp.exe. I noticed that the version of gcc shipped with cygwin is 2.95.3-5. Is the '-5' some form of Cygwin specific patch with some assorted magic in it? Perhaps someone on this list would know. cheers, Kris - Original Message - From: "Dan Vasaru" <[EMAIL PROTECTED]> To: "Kris Warkentin" <[EMAIL PROTECTED]> Sent: Tuesday, October 01, 2002 4:18 PM Subject: RE: CR/NL problem with cpp.exe > Sorry about that, I set out to write a longer reply (which I posted to the > group) and typed CTRL+ENTER just as I got started. > > If what I wrote to the group doesn't help, (opening your files with O_TEXT, > and setting stdin to textmode), then I believe you have a problem. > 1. What type are your mounts (where your c files reside) > 2. What is the value of the CYGWIN variable ? > > Dan > -Original Message- > From: Kris Warkentin [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 01, 2002 10:04 PM > To: Dan Vasaru > Subject: Re: CR/NL problem with cpp.exe > > > - Original Message - > From: "Dan Vasaru" <[EMAIL PROTECTED]> > To: "Kris Warkentin" <[EMAIL PROTECTED]> > Sent: Tuesday, October 01, 2002 3:48 PM > Subject: RE: CR/NL problem with cpp.exe > > > > Kris, > > > > Please refer to this section of the FAQ: > > > > Which section? I've read the CR/NL sections of the FAQ and I believe I > understand the issue at hand. > > 1) Two versions of cpp.exe, both compiled under cygwin, both running under > same environment with the same input from the same filesystem. > 2) The code for cpp.exe doesn't do anything special but rather just checks > for '\\' '\n' at the end of a line. > 3) The cpp.exe shipped with Cygwin works fine - input translation takes > place just as the FAQ states - the open() call opens them in O_TEXT mode. > 4) The cpp.exe that we built does not get the benefit of this input > translation. > > As near as I can tell, our cpp.exe should 'just work' and yet it doesn't. > Any suggestions? > > cheers, > > Kris > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: multithread C lib -- LIBCMT.LIB
Jie, LIBCMT is the Microsoft implementation of the C runtime, and is compiled using the microsoft c compiler. CYGWIN is another implementation of the a unix-style C runtime, and the two of them don't mix. The _beginthread and _endthread calls are Microsoft specific extensions to the C standard; they respectively start and end a thread, performing Microsoft C runtime initialization and cleanup. The corresponding Cygwin primitives are called posix_create and posix_end. You may get lucky and get your code working by just substituting pthread_create for beginthread, and pthread_exit for endthread. Mind the function signatures and return types though. For more about pthread_create/exit, check the man page at: http://unixhelp.ed.ac.uk/CGI/man-cgi?pthread_create+3 Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jie Meng Sent: Wednesday, October 16, 2002 9:34 PM To: [EMAIL PROTECTED] Subject: multithread C lib -- LIBCMT.LIB Hi, Is LIBCMT.LIB available with CYGWIN gcc? If not, what is an better alternatives? I have a C program for a device that calls _beginthread and _endthread directly. I have only CYGWIN gcc on my Windows XP now. MSDN has LIBCMT.LIB. Any help would be greatly appreciated. Please send your reply to [EMAIL PROTECTED] Regards, Jie -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: starting a CYGWIN app from a Windows Service
Mark, As Chris suggested, if you want consistent behaviour under cygwin, always open text files in text mode (O_TEXT or "rt"). Even better, wrt portability to Unix platforms, is to: 1. open the file in binary mode 2. be prepared to accept both CRLF- and LF-style text files (i.e. strip the CR yourself) This way, your software will always "behave" when encountering a Windows file while running on a Unix platform. Dan PS. To explain the behaviour you're seeing you have to check 4 places: value of the CYGWIN environment variable when running as a service value of the CYGWIN environment variable when running as yourself system mount types user mount types There's probably a difference in the mount mode or CYGWIN variable between the 2 cases. Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Madsen, Mark Sent: Wednesday, October 16, 2002 11:21 PM To: [EMAIL PROTECTED] Subject: starting a CYGWIN app from a Windows Service When I run an application that uses the cygwin1.dll from either a Windows Service and then from the command line I get different results when trying to read a text file. As a Windows Service: I use fopen and fgets to read a DOS text file and the CR/LF combinations are handled properly. Meaning that I only see the single LF. Running from a DOS command line: Using the exact same executable image as above, both characters are in the buffer. What I know: Both instances use the very same DLL image. (I deleted it and both instances complain about the DLL missing.) Both instances are reading the exact same file, not two different copies. I tried working with the CYGWIN environment variable with no effect on the outcome. Any help would be greatly appreciated. Thanks, Mark -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: starting a cygwin app from a Windows Service
I think you're missing my point, Chris.
I am trying to convince software authors to make their Unix software
compatible with text files creates in the DOS world, at least until libc on
all Unixes of the world implement text translation (which they currently
don't).
This is not a CYGWIN issue, but rather a design decision:
"Should the Linux version of our software XXX be able to read and understand
config files modified in Notepad by our new sysadm which never heard of
dos2unix" ?
Unfortunately, the only solution to accepting both CRLF and LF text files on
ALL platform is to handle the translation yourself.
Dan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Christopher Faylor
Sent: Thursday, October 17, 2002 1:07 AM
To: [EMAIL PROTECTED]
Subject: Re: starting a cygwin app from a Windows Service
On Thu, Oct 17, 2002 at 12:09:35AM +0200, Dan Vasaru wrote:
>Mark,
>
>As Chris suggested, if you want consistent behaviour under cygwin, always
>open text files in text mode (O_TEXT or "rt").
>Even better, wrt portability to Unix platforms, is to:
>
>1. open the file in binary mode
>2. be prepared to accept both CRLF- and LF-style text files (i.e. strip the
>CR yourself)
>
>This way, your software will always "behave" when encountering a Windows
>file while running on a Unix platform.
I don't know. I think it would be far simpler to have something like:
#ifdef __CYGWIN__
# define READTEXT "rt"
#else
# define READTEXT "r"
#endif
.
.
.
FILE fp = fopen ("foo", READTEXT);
rather than reinvent the CRLF handling that already exists in the cygwin
DLL.
Another option is to link with /usr/lib/automode.o or /usr/lib/textmode.o .
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[package bug] protoize missing from gcc3 and gcc2
What happened to protoize & unprotoize ? They used to be in gcc-2.95-3-5, but they are nowhere to be found in the new gcc/gcc2: It was there: http://cygwin.com/cgi-bin2/package-cat.cgi?file=gcc/gcc-2.95.3-5&grep=protoi ze But they are neither here http://cygwin.com/cgi-bin2/package-cat.cgi?file=gcc2/gcc2-2.95.3-10 nor there: http://cygwin.com/cgi-bin2/package-cat.cgi?file=gcc/gcc-3.2-1 Of course, they are still in the source packages. Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated: gcc-3.2-2
Christopher, Could you please include protoize and unprotoize in the binary distribution ? They were included in 2.95.3-5 but vanished from both 3.2 and 2.95.3-10. Or maybe they are deprecated ? Thank you, Dan -Original Message- From: [EMAIL PROTECTED] [mailto:cygwin-owner@;cygwin.com]On Behalf Of Christopher Faylor Sent: Sunday, November 10, 2002 5:17 PM To: [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Updated: gcc-3.2-2 I've made a new version of gcc available for download. This is a very minor refresh against the released version of gcc 3.2 plus the usual voluminous cygwin + mingw specific patches. However, the only noticeable change from the last release was an attempt to correctly define mbstate_t. [...] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
