File autocomplete behaviour change in current Cygwin
In 1.3.12-4, when I have a testprogram.c and testprogram.exe under the current directory and type ./test [TAB], the system will complete it to ./testprogram.exe, but in 1.3.15-2 only ./testprogram. appears. I noticed that in 1.3.15-2 ntsec is default to on but when I turn ntsec off it still does not work. I must manually chmod -x test.c to make the it work as I desired. I suppose the 1.3.12-4 behaviour is more "desirable", because it is easier to use, esp. when one does not want ntsec. Is it possible to revert to the original behaviour? Best regards, Wu Yongwei -- 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/
SPEWS blocked me
Is SPEWS necessary? I see that the whole DSL IP range of our company's ISP is blocked. Terrible that each user needs to beg the mercy of SPEWS or individually send request to register their e-mail addresses safely to use in Cygwin. No intention to insult. Just feel there may be alternate ways to do that. Once our mail server is blocked by a open relay list, but it is easier to remedy and I feel good that a security hole in our mail server is eliminated. Best regards, Wu Yongwei -- 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: SPEWS blocked me
OK, you might be right. Thanks that you at least provide a way to bypass the foolish "anti-spam" mechanism. The fact is that I hate the way SPEWS works. It thinks it is the crusade and refuses to remove individual IPs. The following is what I got from them: We are blocking 21vianet.com because they ignore spam complaints. When the 21vianet spam stops, the blocks will come down. Not before. If you have a problem, complain to 21vianet. They are the source of your problem. Cameron I don't think I can easily educate my ISP, nor can I switch my ISP because of this. -- But I realize that I am not much better in that I want to "cure" them instead of being "cured" And this is going off-topic. I stop now. Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- > Is SPEWS necessary? I see that the whole DSL IP range of our > company's ISP is blocked. Terrible that each user needs to beg the > mercy of SPEWS or individually send request to register their e-mail > addresses safely to use in Cygwin. Yeah. It's really really terrible isn't it? The horror of having to take an extra five minutes to register yourself. The mind numbing searing pain is almost inconceivable. > No intention to insult. Just feel there may be alternate ways to do > that. Once our mail server is blocked by a open relay list, but it is > easier to remedy and I feel good that a security hole in our mail > server is eliminated. Given that a marjority of the spam that makes it by all of the other filters is blocked by OsiruSoft, I don't think I'm going to be eliminating it anytime soon, especially when you can trivially bypass the block. 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/
Cron Problems
I successfully ran some simple cron jobs under Cygwin, but two things puzzled me. 1) There are always some error messages in Event Log Viewer when running cron or crontab. The error messages are like "Description of event ID (0) cannot be found (in resource (cron)). There might be missing registry information ... crontab : Win32 Process Id = 0x34C : Cygwin Process Id = 0x340 : (Administrator) REPLACE (Administrator)" and "... /usr/sbin/cron : Win32 Process Id = 0x410 : Cygwin Process Id = 0x410 : (CRON) STARTUP (fork ok)" (this is a back-translation since I am using a Chinese system). However, the scheduled job is successfully done. 2) How to start cron when starting the computer? I tried running it as a service in cygrunsrv (cygrunsrv -I cron -p /usr/sbin/cron), but failed since starting the service always failed (cron : Win32 Process Id = 0x3F8 : Cygwin Process Id = 0x3F8 : starting service `cron' failed: execv: 0, No error.) but the process cron appeared. Thanks in advance. Best regards, Wu Yongwei P.S. When starting cron from a command prompt or shell, the process will be bound to the command prompt or shell, i.e., when the command prompt or shell exits, the cron process will exit too. My method of curing this problem is to change byte 0xDC of cron.exe from 03 to 02 (CUI to GUI). Any better methods? -- 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: Cron Problems
Thanks. However, where can I find the options of cron? Now I only find some info in /usr/doc/Cygwin/cron.README, but only in the ChangeLog section, which I ignored on the first reading! And what is the use of the option -a? Best regards, Wu Yongwei --- Original Message from Elfyn McBratney --- > 2) How to start cron when starting the computer? I tried running it > as a service in cygrunsrv (cygrunsrv -I cron -p /usr/sbin/cron), but > failed since starting the service always failed (cron : Win32 Process > Id = 0x3F8 : Cygwin Process Id = 0x3F8 : starting service `cron' > failed: execv: 0, No error.) but the process cron appeared. Your problem is that your not passing the -D (Do not kill off parent process; which allows cron to be used by the service manager) option. So you need to append `-a -D' to your cygrunsrv line when installing cron. Regards, Elfyn McBratney -- 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/
cygwin1.dll, nontsec, and NTFS disk issue
With newer versions of cygwin1.dll (maybe 1.3.15 and later), the ntsec/nontsec behaviour has changed. Now ntsec is the default, and even when nontsec is specified, the command-line autocomplete still behaves like ntsec when operating on a NTFS disk, i.e., when I have a test.c and a test.exe, ". / t e s t TAB" will bring only "./test." instead of the expected "./test.exe". I don't think it affects many people, but it really frets me. I stayed with cygwin 1.3.12-4 for a long while, but now I see more and more packages depend on new features of newer versions of cygwin Thanks for any possible help/suggestions. Best regards, Wu Yongwei -- 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: cygwin1.dll, nontsec, and NTFS disk issue
You are correct about file permissions, Christopher. We all know that Windows has loose file permissions and all files are marked executable by default. When CYGWIN=nontsec, Old behaviour: when an executable is wanted, the system will check by extension and content, not file permissions; New behaviour: when an executable is wanted, the system will check by file permissions on NTFS disks, even though nontsec is set. As far as I understand, it seems to be an overriding issue. For older cygwin versions, ntsec/nontsec overrides system support for file permissions; for newer versions, system support for file permissions makes cygwin ignore ntsec/nontsec setting when autocompleting. That is, the old behaviour only occurs on FAT disks. I think the old way is more consistent. Hope I am clearer. Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- I think that the point is supposed to be that test.c must have executable permissions even with CYGWIN=nontsec. So hitting tab to get what should just be a command brings in test.c, too. I can't duplicate this behavior, of course. 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/
Re: cygwin1.dll, nontsec, and NTFS disk issue
THANKS. Your message solved my problem. I used to set CYGWIN=nontsec in my .bashrc. Now I set it in cygwin.bat, and all works well. Best regards, Wu Yongwei --- Original Message from Max Bowsher --- > New behaviour: when an executable is wanted, the system will check by > file permissions on NTFS disks, even though nontsec is set. ^^ You *are* setting nontsec *before* starting bash, right? Max. -- 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/
Problem with inline assembly in winbase.h
Please have a look at http://article.gmane.org/gmane.comp.gnu.mingw.devel/976 for the discussions. The inline versions lack "memory" clobber and could cause problems as Danny showed. Best regards Wu Yongwei -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Long duration of close(socket) and signal problem
To compare the network performance of Cygwin and native WinSock, I wrote the attached code. Under the three compiler (MinGW 1.1 GCC 2.95, Cygwin GCC 2.95, GCC 2.96 of Red Hat 7.1) I used, I typed only "gcc -Wall fakeweb.c -o fakeweb" to build. Then I used a Web stress tool to send HTTP GET requests repeatedly (like ApacheBench, try "ab -n 100 -c 1 x.x.x.x/" on a Linux box). To my great surprise, the close(socket) operation took EXTREMELY long. It took 0.11 second (CPU usage was low), while this operation under MinGW 1.1 on the same machine took only 0.00019 second. On another Linux machine, close took 0.43 second. Another problem concerns signal handling. This program could be stopped by CTRL-C under MinGW and Linux, but it hung and used 100% of CPU under Cygwin when CTRL-C was hit. Any help? Best regards, Wu Yongwei P.S. On a last test, one strange thing happened. If I reload 127.0.0.1 in a local browser quickly while running fakeweb, the displayed close time is much smaller. It does not work on a remote browser. Just wrote it here and does not expect an explanation for this point. fakeweb.c Description: Binary data pctimer.h Description: Binary data -- 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/
New Setup 2.194.2.15 has problems
Check the attachments for facial problems. It occurs on Far East Windows (I use Chinese). Fonts should be specifically set (for column titles in Pict. 3) and dialog be resized to avoid this kind of problems. And this setup is foolish enough to try to install newer versions of packages from Local Directory while they are not downloaded at all (when I chose to download only some of the new packages)! And it even uninstalled the old packages without installing anything if I just click Next and so on. Best regards, Wu Yongwei cygsetup1.png Description: PNG image cygsetup2.png Description: PNG image cygsetup3.png Description: PNG image -- 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/
PostgreSQL 7.2 won't start as service
7.1.3 is running well as service on my Windows 2000 box. After installing 7.2 the service won't start. Reinstalled 7.1.3 and it is now OK. Currently I have not investigated into the problem and am just comfortable with 7.1.3 Best regards, Wu Yongwei -- 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/
Cygwin1.dll bug in ftime
Today I found this bug when running my synctime program. It always displays
the wrong timezone and thus cannot synchronize correctly. A little
investigation shows that it is ftime in cygwin1.dll that caused the problem.
This is the minimal test case:
#include
#include
int main()
{
struct timeb timebuffer;
ftime(&timebuffer);
printf("%d\n", timebuffer.timezone);
return 0;
}
I am in China and this program should output -480, but with either
cygwin1.dll version 1.3.10 or 1.3.9 it outputs a strange number. :-(
I tried an early version dll (1003.3.0.0), and all is OK. But other parts of
Cygwin seems to require a newer version. I do hope a fix very soon.
Oh yes, I am running Chinese Windows 2000. I wish it was not a
platform-specific problem.
Best regards,
Wu Yongwei
--
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: Cygwin1.dll bug in ftime
More tests show that gettimeofday has problems with timezones, too! Just terrible. Best regards, Wu Yongwei -- 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: cygwin1.dll bug in ftime
Thank you for your response, and I do see some reasonableness in your message. However, I can hardly calm down unless someone can answer: 1) Why should Cygwin break both backward compatibility with older versions and compatibility Linux? 2) If ftime does not need to get timezone information, how about gettimeofday? I did not read the documentation you quoted (where is it?), but no documentation I read about gettimeofday states that it should ignore the timezone argument. My program used to run on both Cygwin and Linux. But now I even do not know how to make it behave like before except that I try to find an old version of Cygwin and revert to it. Or I could use some ugly macros to define _timezone as timezone in some cases and use _timezone: Cygwin recognizes _timezone as a valid global variable while Linux recognizes only timezone. Anybody enlightens me to show me the right way to go? Or should I abandon running international time-related program on Cygwin in a cross-platform way? Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- On Fri, Mar 22, 2002 at 06:24:00PM +0800, Wu Yongwei wrote: >More tests show that gettimeofday has problems with timezones, too! Calm down. >Just terrible. Yeah, we're mean. int gettimeofday(struct timeval *tp, void *tzp); DESCRIPTION The gettimeofday() function obtains the current time, expressed as seconds and microseconds since 00:00 Coordinated Universal Time (UTC), January 1, 1970, and stores it in the timeval structure pointed to by tp. The resolution of the system clock is unspecified. If tzp is not a null pointer, the behaviour is unspecified. int ftime(struct timeb *tp); DESCRIPTION The ftime() function sets the time and millitm members of the timeb structure pointed to by tp to contain the seconds and milliseconds portions, respectively, of the current time in seconds since 00:00:00 UTC (Coordinated Universal Time), January 1, 1970. The contents of the timezone and dstflag members of tp after a call to ftime() are unspecified. 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/
Re: cygwin1.dll bug in ftime
This is from the glibc documentation (is glibc meaningless to the Cygwin project?): Function: int gettimeofday (struct timeval *tp, struct timezone *tzp) The gettimeofday function returns the current calendar time as the elapsed time since the epoch in the struct timeval structure indicated by tp. (see section 21.2 Elapsed Time for a description of struct timespec). Information about the time zone is returned in the structure pointed at tzp. If the tzp argument is a null pointer, time zone information is ignored. The return value is 0 on success and -1 on failure. The following errno error condition is defined for this function: ENOSYS The operating system does not support getting time zone information, and tzp is not a null pointer. The GNU operating system does not support using struct timezone to represent time zone information; that is an obsolete feature of 4.3 BSD. Instead, use the facilities described in 21.4.8 Functions and Variables for Time Zones. I do not understand you quite clearly. And I want to emphasize again that IT USED TO WORK! Do I need to write patches so that the code is unpatched? Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- On Mon, Mar 25, 2002 at 10:45:09AM +0800, Wu Yongwei wrote: >Thank you for your response, and I do see some reasonableness in your >message. However, I can hardly calm down unless someone can answer: > >1) Why should Cygwin break both backward compatibility with older versions >and compatibility Linux? Basic meanness. >2) If ftime does not need to get timezone information, how about >gettimeofday? Look again. I quoted the Single Unix Specification for both gettimeofday and ftime. >I did not read the documentation you quoted (where is it?), >but no documentation I read about gettimeofday states that it should >ignore the timezone argument. http://www.opengroup.org/onlinepubs/7908799/index.html >My program used to run on both Cygwin and Linux. But now I even do not know >how to make it behave like before except that I try to find an old version >of Cygwin and revert to it. Or I could use some ugly macros to define >_timezone as timezone in some cases and use _timezone: Cygwin recognizes >_timezone as a valid global variable while Linux recognizes only timezone. >Anybody enlightens me to show me the right way to go? Or should I abandon >running international time-related program on Cygwin in a cross-platform >way? You could always submit a patch. 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/
Re: cygwin1.dll bug in ftime
Also notes the usage of "unspecified". "Unspecified" means the standard does not say anything about the implementation, and, IMHO, the implementors are free to choose the best practices. I think it is obviously a good way to follow BSD. Am I wrong? Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- int gettimeofday(struct timeval *tp, void *tzp); DESCRIPTION The gettimeofday() function obtains the current time, expressed as seconds and microseconds since 00:00 Coordinated Universal Time (UTC), January 1, 1970, and stores it in the timeval structure pointed to by tp. The resolution of the system clock is unspecified. If tzp is not a null pointer, the behaviour is unspecified. int ftime(struct timeb *tp); DESCRIPTION The ftime() function sets the time and millitm members of the timeb structure pointed to by tp to contain the seconds and milliseconds portions, respectively, of the current time in seconds since 00:00:00 UTC (Coordinated Universal Time), January 1, 1970. The contents of the timezone and dstflag members of tp after a call to ftime() are unspecified. -- 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: cygwin1.dll bug in ftime
Thank you for your suggestions. The points are: 1) Cygwin did very well, but not now; 2) I was not using ftime to get time, but to get timezone information. 3) timezone variable is not usable in Cygwin. So timezone is now not portable. Cygwin broke some "unportable" code. Best regards, Wu Yongwei "Fleischer, Karsten (K.)" wrote: > > > Also notes the usage of "unspecified". "Unspecified" means > > the standard does > > not say anything about the implementation, and, IMHO, the > > implementors are > > free to choose the best practices. > > ... or to not implement anything at all. > > > I think it is obviously a > > good way to > > follow BSD. > > Possibly. > The better way for application developers is to follow the Single UNIX > >Specification. > Any application relying on results that are explicitely marked as > "unspecified" in the SUS standard can be considered non-portable. > > >From the SUSv3 documentation: > > APPLICATION USAGE > For applications portability, the time() function should be used to > determine the current time instead of ftime(). > > Karsten -- 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: cygwin1.dll bug in ftime
First I'll answer your question 3. Having defined timezone does not mean it
will work.
#include
#include
int main()
{
tzset();
printf("%ld\n", timezone);
printf("%ld\n", _timezone);
return 0;
}
$ gcc -Wall test.c
test.c: In function `main':
test.c:7: warning: long int format, pointer arg (arg 2)
$ ./a
4198632
-28800
Enough? (Not well tested, uh?)
Second, no one should ignore backward compatibility (M$'s success is partly
owing to this, as well as Unix's popularity), as long as it does not violate
the design rules (standards-conformance, etc.). I don't think, say,
respecting the second argument of gettimeofday is a sin; those not wanting
it can simply pass NULL.
There is a SERIOUS misunderstanding about standards conformance here. An
unusable timezone is a violation, but well-behaved ftime and gettimeofday
are NOT.
Just as the morale of network protocol implementation is: Be generous to
accept, and be prudent to send. So I think in programming we also should
make environments (run-times, librabries) as compatible as possible, and
write applications as portable as possible.
A standard should specify what we SHOULD do, but it never restricts what we
COULD do. Not to mention that what I asked for has long been there in the
UNIX tradition already.
As I have said already, "unspecified" in a standard means the standard does
not say anything about the implementation, and, IMHO, the implementors are
free to choose from the best practices. Better practices mean better
compatibility, don't they?
Summary of my points. Making ftime and gettimeofday get timezone information
is not a violation of any standards, and will make Cygwin only better
(unless someone thinks better compatibility is a sin).
Hope I am clear enough. I am arguing here for a BETTER Cygwin.
Best regards,
Wu Yongwei
--- Original Message from Karsten Fleischer ---
> Thank you for your suggestions. The points are:
>
> 1) Cygwin did very well, but not now;
That's irrelevant, Cygwin's behavior is SUSv2 compliant, AFAICS.
> 2) I was not using ftime to get time, but to get timezone information.
OK, another quote from the SUSv3 docs
http://www.opengroup.org/onlinepubs/007904975/functions/ftime.html:
--->>
FUTURE DIRECTIONS
This function may be withdrawn in a future version.
<<---
[This wasn't in the SUSv2 docs, though.]
So, _do not_ use this function to get time or timezone information.
> 3) timezone variable is not usable in Cygwin.
Why not?
In my installation 1.3.10 installation I see this in the header
file:
--->>
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
<<---
And _timezone is declared some lines above:
--->>
extern __IMPORT time_t _timezone;
<<---
This is not strictly following the SUSv2 or SUSv3 standards, but it
should work.
SUSv2 says:
--->>
The following are declared as variables:
extern int daylight;
extern long int timezone;
extern char *tzname[];
<<---
SUSv3 says:
--->>
The following shall be declared as variables:
extern intdaylight;
extern long timezone;
extern char *tzname[];
<<---
timezone is a macro on Cygwin, but the typecast is OK.
You can dig through the Cygwin sources and send in a patch to make
Cygwin fully SUS compliant.
> So timezone is now not portable. Cygwin broke some "unportable" code.
It didn't talk about "unportable" code.
What I was trying to say is, that you wrote code that doesn't follow the
standards and that is likely to break on any other platform.
Read the SUSv2 at the link that Christopher Faylor gave you already.
SUSv3 is quite new, so it's likely that other platforms are not really
compliant to this new standard, yet.
Karsten
--
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: cygwin1.dll bug in ftime
When I write new code, _I_ will not use ftime again. In fact, I have fixed my synctime program with an ugly "ifndef __CYGWIN__" macro and replaced code using ftime with _timezone (timezone). However, breaking legacy code is not good behaviour for a (runtime) environment. Also, I don't intend my code will run on any platforms. In fact, seldom will any code with a little complexity without real-environment test. I DO want my code to run flawlessly on frequently-used x86 Unix enviroments, Linux, FreeBSD, Cygwin, etc. Sorry that I do not understand your English very well. But I hope I have expressed my meanings. Best regards, Wu Yongwei --- Original Message from Randall R Schulz --- Yongwei, At 18:45 2002-03-25, you wrote: >... > >Hope I am clear enough. I am arguing here for a BETTER Cygwin. No. You're asking to be let off the hook for either writing intrinsically portable code or of featuring it with conditional compilation directives so that it functions as you want it to on all platforms you want to claim to support. -- 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/
timezone bug and possible patch
time.h, l. 77 #if timezonevar #ifndef timezone #define timezone ((long int) _timezone) #endif #else char *_EXFUN(timezone, (void)); #endif So by default timezone is defined as a function. I am not sure whether this is a violation of standards. If it is, maybe we could use: #ifndef timezonefunc #ifndef timezone #define timezone ((long int) _timezone) #endif #else char *_EXFUN(timezone, (void)); #endif Best regards, Wu Yongwei -- 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: cygwin1.dll bug in ftime (patch included)
OK, here is the patch for src/winsup/cygwin/times.cc:
--- times.cc.oldTue Mar 26 11:36:53 2002
+++ times.ccTue Mar 26 11:53:42 2002
@@ -156,4 +156,5 @@
{
static hires gtod;
+ static tzflag;
LONGLONG now = gtod.usecs (false);
if (now == (LONGLONG) -1)
@@ -162,4 +163,15 @@
tv->tv_sec = now / 100;
tv->tv_usec = now % 100;
+
+ if (tz != NULL)
+{
+ if (!tzflag) {
+tzset();
+tzflag = 1;
+ }
+ tz->tz_minuteswest = _timezone / 60;
+ tz->tz_dsttime = _daylight;
+}
+
return 0;
}
I did not submit a patch because I did not think you will accept it. Writing
the patch itself is easy: it was already there in an old CVS version. Or
almost so. Notice that I do not always call tzset. My previous experience
with MSVC indicates that calling tzset is costly. I am not sure of the case
with Cygwin. However, it is just there for you to review.
Best regards,
Wu Yongwei
--- Original Message from Christopher Faylor ---
On Tue, Mar 26, 2002 at 10:45:32AM +0800, Wu Yongwei wrote:
>Hope I am clear enough. I am arguing here for a BETTER Cygwin.
I guess I wasn't clear enough.
SUPPLY A PATCH TO FIX THE BEHAVIOR.
If you want me, or anyone else to fix it, you'll undoubtedly have a long
wait. Especially since you have now polarized me by arguing points when
you could have been investigating the code and supplying a fix.
No arguments in the world work better than an actual patch.
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/
Re: cygwin1.dll bug in ftime
Glibc is at least an important implementation. Don't we need compatibility? Note that my quotation says about "the GNU operating system", and even at that time gettimeofday should return -1 and set errno. Cygwin does not do it. I wrote the patch. I argue for its legitimacy. In fact, it is scroll-back. I just (mostly) picked code from an old version. Maybe I am wrong to say "obvious". However, is following a way that breaks less code a worse way? If following BSD does not harm anybody and keep more code happily running, WHY NOT? I have said about changing the code in another message. I don't think I need to repeat again. Best regards, Wu Yongwei --- Original Message from J. J. Farrell --- From: "Wu Yongwei" <[EMAIL PROTECTED]>> > This is from the glibc documentation (is glibc meaningless to the Cygwin > project?): I'm not sure what you mean by "meaningless", but glibc is of no particular relevance to Cygwin. > ... > The GNU operating system does not support using struct > timezone to represent time zone information; that is an > obsolete feature of 4.3 BSD. Instead, use the facilities > described in 21.4.8 Functions and Variables for Time Zones. You quote documentation that tells you not to do what you are doing. > I do not understand you quite clearly. And I want to emphasize again that IT > USED TO WORK! Do I need to write patches so that the code is unpatched? If anything is going to change, somebody has to write patches. If you're the one that wants it to change, it seems reasonable that you should be the one who writes the patches. > Also notes the usage of "unspecified". "Unspecified" means the standard does > not say anything about the implementation, and, IMHO, the implementors are > free to choose the best practices. I think it is obviously a good way to > follow BSD. > > Am I wrong? You're wrong to say that it's obvious. Why is it better to follow BSD than any other version of UNIX? Why is it better to do anything in particular with an obsolete feature that has been deprecated for many many years? > Thank you for your suggestions. The points are: > > 1) Cygwin did very well, but not now; > > 2) I was not using ftime to get time, but to get timezone information. > > 3) timezone variable is not usable in Cygwin. > > So timezone is now not portable. Cygwin broke some "unportable" code. Is that a surprise? Unportable code, by definition, is likely to break between different releases of an OS, and between different OSes. Instead of spending time complaining here, you'd be better off generating patches to introduce the behaviour you want. Even better, spend the time changing your code to use the standard portable ways of doing what you want to do. -- 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: cygwin1.dll bug in ftime
Sorry, Christopher, but I thought I needed to answer others' questions and clear myself. Because I need to copy and paste the content of your messages to my reply (I don't want the garbage produced by Lotus Notes to interfere), I can hardly write just below the original message and maybe the correlation of my reply and the original message is not very clear. Linux man page emphasizes the obsoleteness of tz_dsttime field, IMHO, because of the complexity to get this information. Linux DOES use the timezone struct (I tested on Red Hat 7). -- For Heribert, I don't want ENOSYS. I just replied to refute the statement that I had been refuting myself. Sorry for my ignoring your information that I should submit a patch. It seems I did not understand the culture of this mailing list very well as a newbie. I apologize here. ChangeLog: gettimeofday and ftime now set timezone information. Just of interest, who reviews and tests the code? Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- On Tue, Mar 26, 2002 at 09:41:11PM +0800, Wu Yongwei wrote: >Glibc is at least an important implementation. Don't we need compatibility? No. Why are you asking this question again? Didn't you actually quote the linux man page which says not to use the second argument in gettimeofday? "The use of the timezone struct is obsolete; the tz_dsttime field has never been used under Linux - it has not been and will not be supported by libc or glibc. Each and every occurrence of this field in the kernel source (other than the declaration) is a bug." >Note that my quotation says about "the GNU operating system", and even at >that time gettimeofday should return -1 and set errno. Cygwin does not do >it. Nor, should it. Linux doesn't either. You could easily check this before offering opinions on implementation. >I wrote the patch. I argue for its legitimacy. In fact, it is scroll-back. I >just (mostly) picked code from an old version. I have twice suggested that you submit a patch. There is no need to argue about anything. >Maybe I am wrong to say "obvious". However, is following a way that breaks >less code a worse way? If following BSD does not harm anybody and keep more >code happily running, WHY NOT? Apparently, you like to argue but don't like to read too closely. I already suggested that you submit a patch but it took several messages for you to do that. Now, you've submitted a patch but you're still offering invalid arguments about the way things should work. Just give it a rest. Oh, by the way, as usual, I would appreciate a ChangeLog with your patch. One goal in submitting patches is to reduce the workload of the person reviewing it as much as possible so that it would be reviewed quickly. See http://cygwin.com/contrib.html . 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/
ip.h & tcp.h
I noticed that these two header files in /usr/include/netinet is really missing. I have been using the ones from FreeBSD and that fit very well. I just need to add the following lines to the beginning of ip.h: /* Added by Wu Yongwei */ #ifndef LITTLE_ENDIAN #define LITTLE_ENDIAN 1234 #define BIG_ENDIAN 4321 #endif #ifndef BYTE_ORDER #define BYTE_ORDER LITTLE_ENDIAN #endif Could Cygwin just use the modified FreeBSD files, or are there any other considerations? I don't think there are any licence issues -- it only asks for an acknowledgement in ads. (BTW, udp.h is good, too.) Best regards, Wu Yongwei -- 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: ip.h & tcp.h
Um, no one willing to answer? OK, I am changing my request now. CAN CYGWIN DROP IP.H AND TCP.H IN DISTRIBUTION FOR NOW? Reasons: 1. They are empty and so they do not help. They may even frustrate users because it is more difficult to find the cause from a lot of parse errors than a simple "cannot find xxx.h" or so. 2. They harms. I have put new ip.h and tcp.h under /usr/include/netinet to ease compilation of *NIX code. But they will be overwritten sometimes by updating my Cygwin installation. Best regards, Wu Yongwei - Original Message ----- From: "Wu Yongwei" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 03, 2002 9:59 AM Subject: ip.h & tcp.h > I noticed that these two header files in /usr/include/netinet is really > missing. I have been using the ones from FreeBSD and that fit very well. I > just need to add the following lines to the beginning of ip.h: > > /* Added by Wu Yongwei */ > #ifndef LITTLE_ENDIAN > #define LITTLE_ENDIAN 1234 > #define BIG_ENDIAN 4321 > #endif > #ifndef BYTE_ORDER > #define BYTE_ORDER LITTLE_ENDIAN > #endif > > Could Cygwin just use the modified FreeBSD files, or are there any other > considerations? I don't think there are any licence issues -- it only asks > for an acknowledgement in ads. (BTW, udp.h is good, too.) > > Best regards, > > Wu Yongwei -- 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: ip.h & tcp.h
Thank you for all the responses, even the one telling me not to SHOUT. A message is better than nothing, and I shouted because it seemed no one noticed my message. But I am not here to argue. I ask. Should I simply supply the ip.h, tcp.h, and udp.h here? I did not because I am not sure about the licence issue. And I asked first. Maybe I should state again that using the BSD files I successfully built my Linux project on Windows. It uses BSD-style TCP and UDP struct definition. Best regards, Wu Yongwei -- 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: ip.h & tcp.h
Christopher Faylor wrote: >On Mon, Apr 08, 2002 at 10:00:58AM +0800, Wu Yongwei wrote: >>Thank you for all the responses, even the one telling me not to SHOUT. A >>message is better than nothing, and I shouted because it seemed no one >>noticed my message. >> >>But I am not here to argue. I ask. Should I simply supply the ip.h, tcp.h, >>and udp.h here? I did not because I am not sure about the licence issue. >>And I asked first. > >You DO NOT "simply supply" anything. I suggested that you supply a >patch, as I have done repeatedly in the past. I gave you the URL that >explains what you need to do. Yes, I will if I do anything at all. I have already mentioned that the current ip.h and tcp.h are empty. But they are there to overwrite mine. > >If you are going to be copying directly from some other file, then of >course there are licensing issues. I asked whether there are any policies on adopting other header files (open source), but no one answered. By the way, Linux includes the BSD header too. > >You should just adapt whatever you need from the Single UNIX >Specification. Sorry but SUSv2 says nothing about the struct definitions. Or at least I cannot get any meaningful search results. > >I'll leave it to the collective wisdom of this mailing list to help you >on your painful road of enlightenment with regard to submitting a patch. >Your last effort was a good first try but you still have a ways to go. I know what a patch is. But I would like to ask, plan, and do. It is really painful to learn to first do and then ask. > >cgf Wu Yongwei -- 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: ip.h & tcp.h
ChangeLog: BSD-style header files ip.h, tcp.h, and udp.h are added, which include definitions for IP, TCP, and UDP packet header structures. Positions: * ip.h.diff is against /usr/include/netinet/ip.h * tcp.h.diff is against /usr/include/netinet/tcp.h * udp.h should be added to /usr/include/netinet * ip.h in /usr/include/cygwin contains only a comment and I suppose it could be dropped. BSD licence: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. Best regards, Wu Yongwei ip.h.diff Description: Binary data tcp.h.diff Description: Binary data udp.h Description: Binary data -- 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/
Bug of Setup 2.194.2.24 running in "Install from Local Directory"
I reported this bug before, but since it was not fixed in the new release, I am reporting again. When I chose "Download" and skipped some downloads, and then "install from local directory", setup will still try to install the newer packages that do not exist locally. Setup ver. 2.125.2.10 has not this problem (will choose the existing versions), which I like better and use now for downloading and upgrading. The new user interface has problems too on Chinese Windows. Since you do not have the environment I do not expect to see it fixed soon (I am not good at interfaces). I only hope that no big changes will make 2.125.2.10 obsolete. I really like that version. Best regards, Wu Yongwei -- 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/
Where can I find the source of Cygwin setup
Maybe a foolish question, but I did not find it. A CVS tree is appreciated. Thanks. Wu Yongwei -- 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/
An updated 2.125 setup possible?
Is it possible to maintain a 2.125 setup? If I am not mistaken, the only current problem is the MD5 checksum in the ini file. We need only to make the 2.125 setup ignore them. The "new" setup should be ideally put in the directory containing setup.exe and be named setup-old.exe. Maybe it is an unwelcome bad idea but the new setup really frets me. I would love to do the above myself if I were able to do it in an hour. But it seems I am really not familar enough with the GNU configuration and Cygwin code itself. Best regards, Wu Yongwei -- 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/
File mode judgement
In the past, Cygwin seemed to judge whether a file is executable on a combination of suffix and content. However, today when I reinstalled Cygwin, I suddenly found that it no more did it. Now on a NTFS volume it depends only on file attributes. 1) Is it a design change? 2) Is it possible to switch back to the old behaviour? Thank you in advance. Reply to this mail address, please. Best regards Wu Yongwei -- 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: File mode judgement
Thank you for so quick a response. Now I see. I set the environment variable CYGWIN to "ntsec" when I was testing inetd service. Now I unset CYGWIN and solved my problem. No, it is not good yet while even the header files and text files installed by Cygwin itself are regarded as "executable" on setup by default. Best regards, Wu Yongwei --- Original Message from "Robert Collins" <[EMAIL PROTECTED]> --- > In the past, Cygwin seemed to judge whether a file is executable on a > combination of suffix and content. However, today when I reinstalled Cygwin, > I suddenly found that it no more did it. Now on a NTFS volume it depends > only on file attributes. > > 1) Is it a design change? Yes. It is much faster to look at file permissions first, and content second. Thats what unix does. The change is activated by CYGWIN=ntsec. > 2) Is it possible to switch back to the old behaviour? AFAIK, no. It shouldn't be needed anyway, just use chmod to set the +x bit on any executables you have. Rob -- 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/
CVS PServer problem
I am running Windows 2000 and have configured inetd correctly -- that is, I suppose so, because now I can access services like FTP and daytime. And then, I 1) added cvspserver to the Windows Services file; 2) added "cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/home/cvs pserver" to /etc/inetd.conf; 3) created /home/cvs and executed cvs init for this directory; 4) created a /home/cvs/CVSROOT/passwd containing "test:QFVdvse1GAVi2:Administrator"; 5) restarted the inetd service. Now I can see from netstat that port 2401 is listening. I set CVSROOT to ":pserver:[EMAIL PROTECTED]:/home/cvs" and I can execute a cvs login using pserver. However, when I try "cvs import...", it always reports setuid failed: Not owner Any ideas? (I can log in to FTP as "Administrator" or "anonymous" and encounter no problems.) Thanks and best regards, Wu Yongwei -- 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: CVS PServer problem
Is there a guide to do so? I configured sshd but still cannot do a remote CVS operation. (BTW, it seems I cannot stop the sshd service installed by ssh-host-config.) Best regards, Wu Yongwei --- Original Message from "Geoff Soutter" --- RTFMLA [Heh. Been waiting to use that one...] Pserver doesn't work yet. Using :external and SSH does. Geoff -- 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/
SSHD problems on Windows 2000 Professional
I am running the latest version (as of minutes ago) of Cygwin and encountered problems of SSHD. I did not found answer in latest posts. I used ssh-host-config to set up sshd. I installed sshd as service and used the default "CYGWIN=binmode tty ntsec". While it started perfectly for the first time and was completely usable, the service even refused to stop. I had to kill sshd.exe in task manager. And then it would not work until the next boot. I tried starting sshd from inetd. It was even worse. When I connected to it from a remote box, there was no response at all. And then sshd.exe hung. Stopping the service inetd would not stop sshd.exe. I could not even kill it. I had to reboot the W2k box. I also tried sshd.exe directly from Cygwin Bash. I would see the prompt for password on a remote box when connecting to it, but the password could not be accepted. It always reports "Permission denied". Any help? (Reply to me, please.) Thanks and best regards, Wu Yongwei -- 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: SSHD problems on Windows 2000 Professional
Yes. But it did not help much. And in later testing I found even the first time the sshd service was started after reboot it still had problems: it would accept ONLY the first login, and later attempts would be denied. Thank you for your kind and quick help, after all. Best regards, Wu Yongwei --- Original Message from Geoff Soutter --- Did you read the cygwin ssh docs in /usr/docs SSHD is not perfect on cygwin but I managed to get it to work running as a service. Inetd is not recommended as far as I remember. -- 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: SSHD problems on Windows 2000 Professional
What are the EXACT requirements for passwd, group, and key file ownership (I do not see how to change ownership to SYSTEM; currently Administrator owns them)? Also notice that the first SSH connection is OK. So I do NOT expect much that my configuration is wrong. I do not think my Windows box has any problems since it has been running very stably. Anyway, I do not see any reason that sshd should halt. I do wish that you could come and see what my problem is. I am a programmer and I know how hateful it is when a customer tells you he has some problems that you think impossible to occur. And some of these problems might platform-specific. And maybe I did not do something that you think even idiot will do Best regards, Wu Yongwei --- Original Message from Corinna Vinschen --- Did you check your passwd and group files, did you check the ownership of the host key files? -- 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: SSHD problems on Windows 2000 Professional
Terribly sorry for my own mistake. I did not try export CYGWIN=ntsec chown SYSTEM ssh_host_* Never thought it would have any difference. I was really not used to using Unix commands in a Windows environment and had not found how to change ownership to SYSTEM by Windows Explorer. Shy. Wu Yongwei P.S. However, is it better to provide more information how to set up sshd for users more accustomed to Windows? --- Original Message from "Corinna Vinschen" --- Did you check your passwd and group files, did you check the ownership of the host key files? -- 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/
