Re: [PATCH] cygcheck parsing of id output

2003-08-14 Thread Christopher Faylor
On Thu, Aug 07, 2003 at 11:36:05AM -0400, Igor Pechtchanski wrote:
>Yet another ping...  3 months and counting -- has this gotten lost?

Sorry.  I'm not interested in adding this added complexity to cygcheck.
I think the current parsing code should be adequate.

cgf


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Corinna Vinschen
On Wed, Aug 13, 2003 at 02:33:57PM -0400, Igor Pechtchanski wrote:
> Ping!  This is pretty urgent, as the code that's currently in CVS won't
> work and has a buffer overflow.
> [...]
> > 2003-08-10  Igor Pechtchanski  <[EMAIL PROTECTED]>
> >
> > * dump_setup.cc (check_package_files): Fix extra '/' in filename.
> > Resize command buffer.  Fix buffer overflow bug.

Applied.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Christopher Faylor
On Sat, Aug 09, 2003 at 03:59:00PM -0400, Igor Pechtchanski wrote:
>On Sat, 9 Aug 2003, Christopher Faylor wrote:
>
>> [snip]
>> Btw, have you considered some kind of rpm -f functionality?  That would
>> allow a user to do a:
>>
>> cygcheck -f /usr/bin/ls.exe
>> fileutils-4.1-2
>>
>> Also some kind of functionality which would allow cygcheck to query
>> the same files as the web search would be really cool.  Something like
>> a:
>>
>> cygcheck --whatprovides /usr/bin/ls.exe
>>
>> would be really useful.
>
>I'm not sure I see the difference between the two cases above.

-f checks the installed database in /etc/setup/package.lst.gz (similar
to rpm -f), --whatprovides checks the "database" on sources.redhat.com
(similar to Red Hat's up2date?).  That's what I meant by "the same files
as the web search".

I don't see why -f wouldn't be relatively trivial to do since we know
have code in cygcheck which uncompresses and opens each of the package
files.  --whatprovides would require a net query, of course.  That would
be more complicated.

>> Another interesting thing would be to do some ntsec/mkpasswd/mkgroup
>> type sanity checks or even to fix up common ntsec problems.
>
>Yeah.  At least have it check for the group name of "mkpasswd" or
>"mkgroup"...  That, however, would require a separate flag, IMO.

Why a separate flag?  Why not always do it with a cygcheck -s?

cgf


[PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Igor Pechtchanski
Hi,

This patch adds most of the capability of the script from
 to cygcheck.
It is triggered by the "-c" flag to cygcheck.  "Integrity" is a rather
strong word, actually, as all this checks for is the existence of files
and directories, but this could be further built upon (for example, tar
has a diff option that could be useful).  The patch is against cvs HEAD
with my previous micropatch
() applied.
Comments and suggestions welcome.
Igor
==
ChangeLog:
2003-08-07  Igor Pechtchanski  <[EMAIL PROTECTED]>

* dump_setup.cc (version_len): New static variable.
(could_not_access,directory_exists,file_exists)
(check_package_files): New static functions.
(dump_setup): Check the contents of each package
if check_files is true and output the result in the
"Status" column.  Flush output after each package.

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton
Index: winsup/utils/dump_setup.cc
===
RCS file: /cvs/src/src/winsup/utils/dump_setup.cc,v
retrieving revision 1.6
diff -u -p -r1.6 dump_setup.cc
--- winsup/utils/dump_setup.cc  7 Feb 2003 21:34:34 -   1.6
+++ winsup/utils/dump_setup.cc  7 Aug 2003 22:34:16 -
@@ -15,9 +15,12 @@ details. */
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "path.h"
 
 static int package_len = 20;
+static unsigned int version_len = 10;
 
 
 typedef struct
@@ -173,8 +176,100 @@ match_argv (char **argv, const char *nam
   return false;
 }
 
+static bool
+could_not_access (int verbose, char *filename, char *package, const char *type)
+{
+  switch (errno)
+{
+  case ENOTDIR:
+break;
+  case ENOENT:
+if (verbose)
+  printf ("Missing %s: /%s from package %s\n",
+  type, filename, package);
+return true;
+  case EACCES:
+if (verbose)
+  printf ("Unable to access %s /%s from package %s\n",
+  type, filename, package);
+return true;
+}
+  return false;
+}
+
+static bool
+directory_exists (int verbose, char *filename, char *package)
+{
+  struct stat status;
+  if (stat(cygpath("/", filename, ".", NULL), &status))
+{
+  if (could_not_access (verbose, filename, package, "directory"))
+return false;
+}
+  else if (!S_ISDIR(status.st_mode))
+{
+  if (verbose)
+printf ("Directory/file mismatch: /%s from package %s\n", filename, package);
+  return false;
+}
+  return true;
+}
+
+static bool
+file_exists (int verbose, char *filename, const char *alt, char *package)
+{
+  struct stat status;
+  if (stat(cygpath("/", filename, NULL), &status) &&
+  (!alt || stat(cygpath("/", filename, alt, NULL), &status)))
+{
+  if (could_not_access (verbose, filename, package, "file"))
+return false;
+}
+  else if (!S_ISREG(status.st_mode))
+{
+  if (verbose)
+printf ("File type mismatch: /%s from package %s\n", filename, package);
+  return false;
+}
+  return true;
+}
+
+static bool
+check_package_files (int verbose, char *package)
+{
+  bool result = true;
+  char filelist[4096] = " -dc /etc/setup/";
+  strcat(strcat(filelist, package), ".lst.gz");
+  char *zcat = cygpath("/bin/gzip.exe", NULL);
+  char command[4096];
+  strcat(strcpy(command, zcat), filelist);
+  FILE *fp = popen (command, "rt");
+  char buf[4096];
+  while (fgets (buf, 4096, fp))
+{
+  char *filename = strtok(buf, "\n");
+  if (filename[strlen(filename)-1] == '/')
+{
+  if (!directory_exists(verbose, filename, package))
+result = false;
+}
+  else if (!strncmp(filename, "etc/postinstall/", 16))
+{
+  if (!file_exists(verbose, filename, ".done", package))
+result = false;
+}
+  else
+{
+  if (!file_exists(verbose, filename, ".lnk", package))
+result = false;
+}
+}
+  fclose(fp);
+  return result;
+}
+
 void
-dump_setup (int verbose, char **argv, bool /*check_files*/)
+dump_setup (int verbose, char **argv, bool check_files)
 {
   char *setup = cygpath ("/etc/setup/installed.db", NULL);
   FILE *fp = fopen (setup, "rt");
@@ -223,6 +318,8 @@ dump_setup (int verbose, char **argv, bo
  if (f.what[0])
strcat (strcat (packages[n].name, "-"), f.what);
  packages[n].ver = s

Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Charles Wilson
Christopher Faylor wrote:


I'll check this in but it would be nice if (WBNI) this used a mingw gzip
library rather than calling gzip directly.  That's a fair amount of
work but I could resurrect the zlib library in winsup if necessary.
I wonder why setup is using gzip rather than bzip2 for the package files...
the setup tree contains its own copies of the zlib and bzlib trees; 
thue, they are compiled under the same runtime that setup is.  If setup 
is a 'mingw' app, then so are the internal, statically linked libz and 
bz2lib.

I imagine that the reason Igor used popen and zcat is simply that it was 
easier than directly interfacing to the library.  Perhaps that issue 
could be addressed in a later patch (along the lines of the compress_gz 
class, which also provides uncompression capabilities?)

--
Chuck



Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Christopher Faylor
On Sun, Aug 10, 2003 at 10:23:47AM +1000, Robert Collins wrote:
>On Sun, 2003-08-10 at 10:12, Christopher Faylor wrote:
>>I don't see how that will ever be possible given the windows problems
>>with stdio and GUI apps.  I guess we could make setup a console utility
>>but that would result in the ugly black console box flashing up
>>whenever you start setup.exe.
>
>I was thinking of something like 'cygsetup' a console only version.
>cygcheck could then call that for the setup-related stuff it does now,
>and these extra features.

That would work.  I do have my recently renamed "cygupdate" package in
the cygwin-apps repository which uses the upset packages to read
setup.ini.  It is basically written in perl and does some command-line
installation things.

I've been tweaking this over time and it is starting to come together
fairly nicely.  The only problem is that, since it is written in perl,
it won't be able to easily use any setup C++ library stuff.  I've been
using it for quick testing of new packages and it is nice to have a
command line setup program where you can capture the output in a file.

cgf


Re: [PATCH] Add support for ioctl TIOCLINUX, function 6 (get key modifiers) on a TTY

2003-08-14 Thread Christopher Faylor
On Sat, Aug 09, 2003 at 01:00:53PM +0200, Pavel Tsekov wrote:
>Should the silence indicate a lack of interest ?

It means I haven't had time to research it yet.  I won't have time for
at least a week.

Corinna alert: Please let me investigate this one.  Thanks.

cgf


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Igor Pechtchanski
On Sat, 9 Aug 2003, Christopher Faylor wrote:

> On Sat, Aug 09, 2003 at 12:29:39PM -0400, Christopher Faylor wrote:
> >On Sat, Aug 09, 2003 at 12:12:11PM -0400, Christopher Faylor wrote:
> >>On Thu, Aug 07, 2003 at 06:50:10PM -0400, Igor Pechtchanski wrote:
> >>>Hi,
> >>>
> >>>This patch adds most of the capability of the script from
> >>> to cygcheck.
> >>>It is triggered by the "-c" flag to cygcheck.  "Integrity" is a rather
> >>>strong word, actually, as all this checks for is the existence of files
> >>>and directories, but this could be further built upon (for example, tar
> >>>has a diff option that could be useful).  The patch is against cvs HEAD
> >>>with my previous micropatch
> >>>() applied.
> >>>Comments and suggestions welcome.
> >>
> >>I'm getting some odd errors when I apply this patch:
> >>
> >>"4NT: Unknown command f:"
> >>
> >>(as you can see I use 4NT).
> >>
> >>I haven't had time to debug where these are coming from but I get one
> >>for every file displayed.
> >
> >The enclosed patch fixes that.
> >
> >I'll check this in but it would be nice if (WBNI) this used a mingw gzip
> >library rather than calling gzip directly.  That's a fair amount of
> >work but I could resurrect the zlib library in winsup if necessary.
> >
> >I wonder why setup is using gzip rather than bzip2 for the package files...
>
> On checking this patch a little further, I see that it gives a
> misleading "OK" when the package file is missing.  Could you detect
> that case?
>
> cgf

Yes.  The attached patch (against the initial one applied) does just that.
Igor
==
ChangeLog:
2003-08-09  Igor Pechtchanski  <[EMAIL PROTECTED]>

* dump_setup.cc (dump_setup): Check for the existence
of the package list file.

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--- dump_setup.cc~  2003-08-07 18:40:22.0 -0400
+++ dump_setup.cc   2003-08-09 15:48:16.0 -0400
@@ -238,11 +238,17 @@ static bool
 check_package_files (int verbose, char *package)
 {
   bool result = true;
-  char filelist[4096] = " -dc /etc/setup/";
+  char filelist[4096] = "etc/setup/";
   strcat(strcat(filelist, package), ".lst.gz");
+  if (!file_exists(false, filelist, NULL, NULL))
+{
+  if (verbose)
+   printf ("Missing file list /%s for package %s\n", filelist, package);
+  return false;
+}
   char *zcat = cygpath("/bin/gzip.exe", NULL);
   char command[4096];
-  strcat(strcpy(command, zcat), filelist);
+  strcat(strcat(strcpy(command, zcat), " -dc /"), filelist);
   FILE *fp = popen (command, "rt");
   char buf[4096];
   while (fgets (buf, 4096, fp))


Re: [PATCH] Add support for ioctl TIOCLINUX, function 6 (get key modifiers) on a TTY

2003-08-14 Thread Pavel Tsekov
Hello,

Should the silence indicate a lack of interest ?

Pavel

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post



Questions and a RFC [was Re: Assignment from Nicholas Wourms arrived]

2003-08-14 Thread Nicholas Wourms
[EMAIL PROTECTED] wrote:
FYI,

your copyright assignment form has been received by Red Hat.  Patch away!

Any outstanding issues besides argz/envz?

Not yet, I've got a few things I'd like to contribute to newlib first.

However, I do have a few questions...

1)Did my MUA strip the tabs from the patch?  The only reason I ask is 
because I had formatted the code with tabs and now it looks like they 
were all converted to spaces.  [BTW, sorry about NBBY, I had been 
meaning to send a follow up since I realized that I forgot that I had it 
globally defined in another header :-(].

2)I assume that my assignment covers me for Newlib contributions?

3)I'm still trying to figure out how to use lstat in newlib source code, 
 since apparently the function declaration is hidden when building 
newlib/cygwin.  So far, any attempt to use it results in undefined 
references to _lstat when linking the dll.  I tried adding a definition 
to _syslist.h, but that didn't work.  I hate to sound clueless, but if 
someone could nudge me toward the right header or magic, that would be 
great.

4)Corinna, I've been working on porting some of the missing 
SUSv3/c99/bsd functions from the *bsd libc.  I noticed that the libutil 
which you distribute with inetutils contains some of the functions I 
thought belonged in libc, or at least the headers of newlib would have 
me believe this.  Specifically, I was wanted to work on adding instances of:
endusershell()
setusershell()
getusershell()
ruserok()
iruserok()

Why would I want to do this you ask?  Well some of the specific 
implementations of the other code I'm tying to port use these functions. 
 I suppose I could just use internal, static versions, but these 
functions really ought to be reusable and in sync with the global 
header.  Do you have any objections to this, provided you find my code 
sound?

5)This is meant as a general RFC based on something I noticed while 
researching the freebsd libc.

What would people think about adding another member to the FILE 
structure which would allow for future additions without 
incompatibilities?  I noticed that freebsd has addressed their growing 
FILE ABI by using adding a new member struct, *_extra, to allow for 
additional members without causing incompatibilities.  As I was working 
on porting fwide(), I ran across this feature in freebsd.  Here's how 
it's done:

In the public header, stdio.h:
--
struct __sFILEX;
...
typedef struct __sFILE {
...
   int (*_write)(void *, const char *, int);
   /* separate buffer for long sequences of ungetc() */
   struct  __sbuf _ub; /*ungetc buffer */
   struct __sFILEX *_extra; /*additions to FILE to not break ABI*/

   int _ur;/*saved _r when _r is counting ungetc*/
...
};
--
Then from private header, local.h, located in the stdio/ dir:
-
struct __sFILEX {
   unsigned char   *_up; /*saved _p when _p is doing ungetc data*/
   pthread_mutex_t fl_mutex;   /* used for MT-safety */
   pthread_t   fl_owner;   /* current owner */
   int fl_count;   /* recursive lock count */
   int orientation;/* orientation for fwide() */
#ifdef notdef
   /*
* XXX These are not used yet -- they will be used to store the
* multibyte conversion state for writing and reading when
* stateful encodings are supported by the locale framework.
*/
   mbstate_t   wstate; /* write conversion state */
   mbstate_t   rstate; /* read conversion state */
#endif
};
-
Planning ahead for future possibilities is always a good thing, so in 
that respect this seems like a sound idea.  Since we are already dealing 
with ABI breakage, I thought I'd float this now to see what people 
think.  Would a change like this be of benefit to Cygwin?

Cheers,
Nicholas


[PATCH] stdint.h define of INT32_MIN

2003-08-14 Thread Gerrit P. Haase
Hallo ,

The Open Group Base Specifications Issue 6 says here:
http://www.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html

"An N-bit signed type has values in the range -2**(N-1) or 1-2**(N-1)
to 2**(N-1)-1, while an N-bit unsigned type has values in the range 0
to 2**(N-1)."

Which is in this case:
 -2**31  = -2147483648
OR
 1-2**31 = -2147483647

Using #define INT32_MIN (-21474836478) breaks the perl build on
Cygwin because this constant is used in some typecasts, and it also
gives my this warning everytime INT32_MIN is used: 

xyz.c:2: warning: this decimal constant is unsigned only in ISO C90

Both of the below patches are ok. for me to build perl and also there
are no warnings issued, the first is the way it is defined on Linux
too, the second seems to be alright according to the SUS specs:

$ diff -udp stdint.h~ stdint.h
--- stdint.h~   2003-08-08 13:14:19.248036800 +0200
+++ stdint.h2003-08-08 13:14:36.452776000 +0200
@@ -70,7 +70,7 @@ typedef unsigned long long uintmax_t;
 
 #define INT8_MIN (-128)
 #define INT16_MIN (-32768)
-#define INT32_MIN (-2147483648)
+#define INT32_MIN (-2147483647-1)
 #define INT64_MIN (-9223372036854775808)
 
 #define INT8_MAX (127)

# END

$ diff -udp stdint.h~ stdint.h
--- stdint.h~   2003-08-08 13:14:19.248036800 +0200
+++ stdint.h2003-08-08 13:15:12.775004800 +0200
@@ -70,7 +70,7 @@ typedef unsigned long long uintmax_t;
 
 #define INT8_MIN (-128)
 #define INT16_MIN (-32768)
-#define INT32_MIN (-2147483648)
+#define INT32_MIN (-2147483647)
 #define INT64_MIN (-9223372036854775808)
 
 #define INT8_MAX (127)

# END

Gerrit
-- 
=^..^=



Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Igor Pechtchanski
On Sat, 9 Aug 2003, Christopher Faylor wrote:

> On Sat, Aug 09, 2003 at 03:52:55PM -0400, Igor Pechtchanski wrote:
> >On Sat, 9 Aug 2003, Christopher Faylor wrote:
> >>On checking this patch a little further, I see that it gives a
> >>misleading "OK" when the package file is missing.  Could you detect
> >>that case?
> >
> >Yes.  The attached patch (against the initial one applied) does just
> >that.
>
> I've checked this in, too, with some changes.  The version of this file
> in CVS had my fix to convert slashes to backslashes so your patch didn't
> cleanly apply.  I also allocated a static buffer and only calculated the
> DOS pathname for gzip.exe once.  Finally, I changed all of the
> formatting to GNU-style.

Ugh, yes, I forgot to do a CVS update...  Sorry about that.  As for the
GNU-style formatting, that space between the function name and the paren
always trips me up...

Anyway, there were some bugs in the code that was checked in -- the
attached patch fixes them.

> Thanks for this increased functionality.  I used this to update my own
> installation.  It looks like I had somehow damaged my installation a
> while ago.  Some files were missing, some package lists were missing.
> Who knew?
>
> cgf

Glad it was useful.
Igor
==
ChangeLog:
2003-08-10  Igor Pechtchanski  <[EMAIL PROTECTED]>

* dump_setup.cc (check_package_files): Fix extra '/' in filename.
Resize command buffer.  Fix buffer overflow bug.

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton
Index: winsup/utils/dump_setup.cc
===
RCS file: /cvs/src/src/winsup/utils/dump_setup.cc,v
retrieving revision 1.8
diff -u -p -r1.8 dump_setup.cc
--- winsup/utils/dump_setup.cc  10 Aug 2003 01:07:04 -  1.8
+++ winsup/utils/dump_setup.cc  10 Aug 2003 19:24:38 -
@@ -237,7 +237,7 @@ file_exists (int verbose, char *filename
 static bool
 check_package_files (int verbose, char *package)
 {
-  char filelist[MAX_PATH + 1] = "/etc/setup/";
+  char filelist[MAX_PATH + 1] = "etc/setup/";
   strcat (strcat (filelist, package), ".lst.gz");
   if (!file_exists (false, filelist, NULL, NULL))
 {
@@ -253,8 +253,8 @@ check_package_files (int verbose, char *
   zcat = cygpath ("/bin/gzip.exe", NULL);
   while (char *p = strchr (zcat, '/'))
*p = '\\';
-  zcat = (char *) realloc (zcat, strlen (zcat) + sizeof (" -dc ") + 4096);
-  zcat_end = strchr (strcat (zcat, " -dc "), '\0');
+  zcat = (char *) realloc (zcat, strlen (zcat) + sizeof (" -dc /") + MAX_PATH);
+  zcat_end = strchr (strcat (zcat, " -dc /"), '\0');
 }
 
   strcpy (zcat_end, filelist);
@@ -262,7 +262,7 @@ check_package_files (int verbose, char *
 
   bool result = true;
   char buf[MAX_PATH + 1];
-  while (fgets (buf, 4096, fp))
+  while (fgets (buf, MAX_PATH, fp))
 {
   char *filename = strtok(buf, "\n");
   if (filename[strlen (filename) - 1] == '/')


[PATCH] Package content search and listing functionality for cygcheck

2003-08-14 Thread Igor Pechtchanski
This patch adds the functionality to cygcheck to list (using the "-l" or
"--list-package" flag) the contents of and search (using the "-f" or
"--find-package" flag and passing the absolute paths to the files) for
files in the *installed* packages.  Please test this and feel free to give
feedback.  I've done some refactoring of the code in dump_setup.cc as
well.  There's still some code duplication, but that can be addressed in a
later patch if it bothers people too much.
Igor
==
ChangeLog:
2003-08-14  Igor Pechtchanski  <[EMAIL PROTECTED]>

* cygcheck.cc (find_package,list_package): New global
variables.
(usage): Add "--find-package" and "--list-package" options,
reformat output.
(longopts, opts): Add "--find-package" and "--list-package"
options.
(main): Process the "--find-package" and "--list-package"
flags.  Add new semantic checks.  Add calls to find_package()
and list_package().
* dump_setup.cc: Fix header comment.
(match_argv): Change return type to int to distinguish
between real matches and default ones.
(open_package_list): New static function.
(check_package_files): Factor out opening the package list
file into open_package_list().
(get_packages): New static function.
(dump_setup): Factor out getting a list of packages into
get_packages().
(package_list, package_find): New global functions.

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Index: cygcheck.cc
===
RCS file: /cvs/src/src/winsup/utils/cygcheck.cc,v
retrieving revision 1.35
diff -u -p -r1.35 cygcheck.cc
--- cygcheck.cc 13 Jun 2003 02:36:12 -  1.35
+++ cygcheck.cc 14 Aug 2003 19:01:11 -
@@ -26,6 +26,8 @@ int sysinfo = 0;
 int givehelp = 0;
 int keycheck = 0;
 int check_setup = 0;
+int find_package = 0;
+int list_package = 0;
 
 #ifdef __GNUC__
 typedef long long longlong;
@@ -34,6 +36,8 @@ typedef __int64 longlong;
 #endif
 
 void dump_setup (int, char **, bool);
+void package_find (int, char **);
+void package_list (int, char **);
 
 static const char version[] = "$Revision: 1.35 $";
 
@@ -1317,13 +1321,15 @@ usage (FILE * stream, int status)
 Usage: cygcheck [OPTIONS] [PROGRAM...]\n\
 Check system information or PROGRAM library dependencies\n\
 \n\
- -c, --check-setup  check packages installed via setup.exe\n\
- -s, --sysinfo  system information (not with -k)\n\
- -v, --verbose  verbose output (indented) (for -s or programs)\n\
- -r, --registry registry search (requires -s)\n\
- -k, --keycheck perform a keyboard check session (not with -s)\n\
- -h, --help give help about the info (not with -c)\n\
- -V, --version  output version information and exit\n\
+ -c, --check-setup   check packages installed via setup.exe\n\
+ -s, --sysinfo   system information (not with -k)\n\
+ -v, --verbose   verbose output (indented) (for -s or programs)\n\
+ -r, --registry  registry search (requires -s)\n\
+ -k, --keycheck  perform a keyboard check session (not with -[scfl])\n\
+ -f, --find-package  find installed packages containing files (not with -[cl])\n\
+ -l, --list-package  list the contents of installed packages (not with -[cf])\n\
+ -h, --help  give help about the info (not with -[cfl])\n\
+ -V, --version   output version information and exit\n\
 You must at least give either -s or -k or a program name\n");
   exit (status);
 }
@@ -1334,12 +1340,14 @@ struct option longopts[] = {
   {"registry", no_argument, NULL, 'r'},
   {"verbose", no_argument, NULL, 'v'},
   {"keycheck", no_argument, NULL, 'k'},
+  {"find-package", no_argument, NULL, 'f'},
+  {"list-package", no_argument, NULL, 'l'},
   {"help", no_argument, NULL, 'h'},
   {"version", no_argument, 0, 'V'},
   {0, no_argument, NULL, 0}
 };
 
-static char opts[] = "chkrsvV";
+static char opts[] = "cfhklrsvV";
 
 static void
 print_version ()
@@ -1387,6 +1395,12 @@ main (int argc, char **argv)
   case 'k':
keycheck = 1;
break;
+  case 'f':
+   find_package = 1;
+   break;
+  case 'l':
+   list_package = 1;
+   break;
   case 'h':
givehelp = 1;
break;
@@ -1405,7 +1419,13 @@ main (int argc, char **argv)
 else
   usage (stderr, 1);
 
-  if ((check_setup || sysinfo) && keycheck)
+  if ((check_setup || sysinfo || find_package || list_package) && keycheck)
+usage (st

Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Igor Pechtchanski
Ping!  This is pretty urgent, as the code that's currently in CVS won't
work and has a buffer overflow.
Igor

On Sun, 10 Aug 2003, Igor Pechtchanski wrote:

> On Sat, 9 Aug 2003, Christopher Faylor wrote:
>
> > On Sat, Aug 09, 2003 at 03:52:55PM -0400, Igor Pechtchanski wrote:
> > >On Sat, 9 Aug 2003, Christopher Faylor wrote:
> > >>On checking this patch a little further, I see that it gives a
> > >>misleading "OK" when the package file is missing.  Could you detect
> > >>that case?
> > >
> > >Yes.  The attached patch (against the initial one applied) does just
> > >that.
> >
> > I've checked this in, too, with some changes.  The version of this file
> > in CVS had my fix to convert slashes to backslashes so your patch didn't
> > cleanly apply.  I also allocated a static buffer and only calculated the
> > DOS pathname for gzip.exe once.  Finally, I changed all of the
> > formatting to GNU-style.
>
> Ugh, yes, I forgot to do a CVS update...  Sorry about that.  As for the
> GNU-style formatting, that space between the function name and the paren
> always trips me up...
>
> Anyway, there were some bugs in the code that was checked in -- the
> attached patch fixes them.
>
> > Thanks for this increased functionality.  I used this to update my own
> > installation.  It looks like I had somehow damaged my installation a
> > while ago.  Some files were missing, some package lists were missing.
> > Who knew?
> >
> > cgf
>
> Glad it was useful.
>   Igor
> ==
> ChangeLog:
> 2003-08-10  Igor Pechtchanski  <[EMAIL PROTECTED]>
>
>   * dump_setup.cc (check_package_files): Fix extra '/' in filename.
>   Resize command buffer.  Fix buffer overflow bug.

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton
Index: winsup/utils/dump_setup.cc
===
RCS file: /cvs/src/src/winsup/utils/dump_setup.cc,v
retrieving revision 1.8
diff -u -p -r1.8 dump_setup.cc
--- winsup/utils/dump_setup.cc  10 Aug 2003 01:07:04 -  1.8
+++ winsup/utils/dump_setup.cc  10 Aug 2003 19:24:38 -
@@ -237,7 +237,7 @@ file_exists (int verbose, char *filename
 static bool
 check_package_files (int verbose, char *package)
 {
-  char filelist[MAX_PATH + 1] = "/etc/setup/";
+  char filelist[MAX_PATH + 1] = "etc/setup/";
   strcat (strcat (filelist, package), ".lst.gz");
   if (!file_exists (false, filelist, NULL, NULL))
 {
@@ -253,8 +253,8 @@ check_package_files (int verbose, char *
   zcat = cygpath ("/bin/gzip.exe", NULL);
   while (char *p = strchr (zcat, '/'))
*p = '\\';
-  zcat = (char *) realloc (zcat, strlen (zcat) + sizeof (" -dc ") + 4096);
-  zcat_end = strchr (strcat (zcat, " -dc "), '\0');
+  zcat = (char *) realloc (zcat, strlen (zcat) + sizeof (" -dc /") + MAX_PATH);
+  zcat_end = strchr (strcat (zcat, " -dc /"), '\0');
 }
 
   strcpy (zcat_end, filelist);
@@ -262,7 +262,7 @@ check_package_files (int verbose, char *
 
   bool result = true;
   char buf[MAX_PATH + 1];
-  while (fgets (buf, 4096, fp))
+  while (fgets (buf, MAX_PATH, fp))
 {
   char *filename = strtok(buf, "\n");
   if (filename[strlen (filename) - 1] == '/')


Re: [PATCH] Consider extensions for special names in managed mode

2003-08-14 Thread Igor Pechtchanski
On Wed, 13 Aug 2003, Corinna Vinschen wrote:

> On Wed, Aug 13, 2003 at 10:19:08AM -0400, Igor Pechtchanski wrote:
> > Yeah.  I promised a patch, didn't I?  *Sigh*.
> > Igor
> > ==
> > 2003-08-13  Igor Pechtchanski  <[EMAIL PROTECTED]>
> >
> > * path.cc (special_name): Add checks for some specials
> > followed by a "." and a FIXME comment.
>
> I leave this to Chris for obvious reasons.
>
> > +  // FIXME: add com0 and {com,lpt}N.*
> >if (strcasematch (s, "nul")
> > +  || strncasematch (s, "nul.", 4)
> >|| strcasematch (s, "aux")
> > +  || strncasematch (s, "aux.", 4)
> >|| strcasematch (s, "prn")
> > +  || strncasematch (s, "prn.", 4)
> >|| strcasematch (s, "con")
> > +  || strncasematch (s, "con.", 4)
> >|| strcasematch (s, "conin$")
> >|| strcasematch (s, "conout$"))
> >  return -1;
>
> Clueless question:  What about sth. like foo.aux?
>
> Corinna

.
"touch foo.aux" works perfectly well even on normal mounts.
I think  is wrong, though.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton



Re: Questions and a RFC [was Re: Assignment from Nicholas Wourms arrived]

2003-08-14 Thread Corinna Vinschen
On Tue, Aug 12, 2003 at 06:55:11PM -0400, Nicholas Wourms wrote:
> 1)Did my MUA strip the tabs from the patch?  The only reason I ask is 

Yes.  The patch already contained spaces.  I see you're using Mozilla/NS7
so I'm wondering how this happened.  AFAIK, Mozilla doesn't touch
attachments.

> [BTW, sorry about NBBY, I had been 
> meaning to send a follow up since I realized that I forgot that I had it 
> globally defined in another header :-(].

No worries.

> 2)I assume that my assignment covers me for Newlib contributions?

No :-)

Long answer:  You don't need any assignment for newlib due to the relaxed
licensing of newlib.

> 3)I'm still trying to figure out how to use lstat in newlib source code, 

What are you trying to implement?  If you need lstat, you're perhaps better
off implementing this in Cygwin instead of newlib.

>  since apparently the function declaration is hidden when building 
> newlib/cygwin.  So far, any attempt to use it results in undefined 
> references to _lstat when linking the dll.  I tried adding a definition 
> to _syslist.h, but that didn't work.  I hate to sound clueless, but if 
> someone could nudge me toward the right header or magic, that would be 
> great.

cd winsup/cygwin
ctags -R .
vi -t cygwin_lstat

However, thinking about this situation, I'm sure it wasn't really clever
to rename lstat to cygwin_lstat.  Your problem to link against it stems
from that fact and other declaration problems has been easilier solved by
just adding a bunch of defines at the top of syscalls.cc.

[...time passes...]

Ok, I've tested to revert the function name from cygwin_lstat to lstat
in syscalls.cc and applied the appropriate patch.  This is transparent
to all applications and should allow to use lstat from newlib as in
libc/sys/linux.

> 4)Corinna, I've been working on porting some of the missing 
> SUSv3/c99/bsd functions from the *bsd libc.  I noticed that the libutil 
> which you distribute with inetutils contains some of the functions I 
> thought belonged in libc, or at least the headers of newlib would have 
> me believe this.  Specifically, I was wanted to work on adding instances of:
> endusershell()
> setusershell()
> getusershell()
> ruserok()
> iruserok()

Don't do this(TM).  The reason is that, first, I have already code for
this in the loop and, second, I have to coordinate this with changing
my inetutils package not to contain the libutil.a anymore at one point.
I appreciate your effort but I'd like to keep these functions in my
hand, even though it might take a bit longer.

Especially I will not do this for 1.5.2 (or 3, whatever will be the first
gold version).  At this point, we should only apply bug fixes and very
obvious stuff.  New functionality should wait for later Cygwin versions.

> 5)This is meant as a general RFC based on something I noticed while 
> researching the freebsd libc.

Sorry, but I agree with Charles and I'm pretty sure Chris will have the
same opinion.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


Re: Questions and a RFC [was Re: Assignment from Nicholas Wourmsarrived]

2003-08-14 Thread Charles Wilson
Nicholas Wourms wrote:

Planning ahead for future possibilities is always a good thing, so in 
that respect this seems like a sound idea.  Since we are already dealing 
with ABI breakage, I thought I'd float this now to see what people 
think.  Would a change like this be of benefit to Cygwin?
Hell no.  I am irrevocably and unalterably opposed to implementing this 
change before 1.5.2 goes gold.

We've already had THREE ABI breakages in the last month.  Now, you want 
to add another one -- to avoid one in the future.

Here's an idea:  lets wait until the NEXT scheduled ABI breakage to do 
yours; then we'll get two for the price of one.

Right now, cygwin-1.5.x is overdue by several months.  It NEEDS to go 
out the door; we can continually add more ABI breakages forever and 
never release a new version...but that's rather silly IMO.

--
Chuck



Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Robert Collins
On Sun, 2003-08-10 at 02:12, Christopher Faylor wrote:
> On Thu, Aug 07, 2003 at 06:50:10PM -0400, Igor Pechtchanski wrote:
> >Hi,
> >

> Also some kind of functionality which would allow cygcheck to query
> the same files as the web search would be really cool.  Something like
> a:
> 
> cygcheck --whatprovides /usr/bin/ls.exe
> 
> would be really useful.


Hmm, I think we're getting into stuff that setup should do itself. We
-do- have command line functionality...


> Another interesting thing would be to do some ntsec/mkpasswd/mkgroup
> type sanity checks or even to fix up common ntsec problems.

That sounds good for cygcheck.

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Robert Collins
On Sun, 2003-08-10 at 02:29, Christopher Faylor wrote:

> I wonder why setup is using gzip rather than bzip2 for the package files...

It's historical. I'm not *planning* on altering that before the
hypothetical dpkg/rpm backend integration.

I'd suggest though, that further cygcheck setup smarts should come by
librarising setup's code, rather than reproducing it - the setup dir
format is likely to change if we find we need to.

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Igor Pechtchanski
On Sat, 9 Aug 2003, Christopher Faylor wrote:

> [snip]
> Btw, have you considered some kind of rpm -f functionality?  That would
> allow a user to do a:
>
> cygcheck -f /usr/bin/ls.exe
> fileutils-4.1-2
>
> Also some kind of functionality which would allow cygcheck to query
> the same files as the web search would be really cool.  Something like
> a:
>
> cygcheck --whatprovides /usr/bin/ls.exe
>
> would be really useful.

I'm not sure I see the difference between the two cases above.  Also, I
think this kind of query would be easier to implement if setup maintained
a more comprehensive database of files keyed by the filename.  I could
whip up something quick and dirty, but let's first decide on whether to
use the zlib library instead of calling gzip.exe -- that wasn't something
I intended to be permanent.

> Another interesting thing would be to do some ntsec/mkpasswd/mkgroup
> type sanity checks or even to fix up common ntsec problems.
>
> cgf

Yeah.  At least have it check for the group name of "mkpasswd" or
"mkgroup"...  That, however, would require a separate flag, IMO.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton



Assignment from Nicholas Wourms arrived

2003-08-14 Thread Corinna Vinschen
FYI,

your copyright assignment form has been received by Red Hat.  Patch away!

Any outstanding issues besides argz/envz?

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


Re: [PATCH] readdir (): Do not set 'errno' if end of dir is encountered

2003-08-14 Thread Christopher Faylor
On Tue, Aug 05, 2003 at 04:49:13AM +0200, Pavel Tsekov wrote:
>2003-08-05  Pavel Tsekov  <[EMAIL PROTECTED]>
>
>   * fhandler_disk_file.cc (fhandler_cygdrive::readdir): Do not change
>   'errno' if end of directory condition is encountered as per SUSv2.
>   * fhandler_proc.cc (fhandler_proc::readdir): Ditto.
>   * fhandler_process (fhandler_process::readdir): Ditto.
>   * fhandler_registry (fhandler_registry::readdir): Ditto.

Applied.

Thanks,
cgf


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Christopher Faylor
On Thu, Aug 07, 2003 at 06:50:10PM -0400, Igor Pechtchanski wrote:
>Hi,
>
>This patch adds most of the capability of the script from
> to cygcheck.
>It is triggered by the "-c" flag to cygcheck.  "Integrity" is a rather
>strong word, actually, as all this checks for is the existence of files
>and directories, but this could be further built upon (for example, tar
>has a diff option that could be useful).  The patch is against cvs HEAD
>with my previous micropatch
>() applied.
>Comments and suggestions welcome.

I'm getting some odd errors when I apply this patch:

"4NT: Unknown command f:"

(as you can see I use 4NT).

I haven't had time to debug where these are coming from but I get one
for every file displayed.

Btw, have you considered some kind of rpm -f functionality?  That would
allow a user to do a:

cygcheck -f /usr/bin/ls.exe
fileutils-4.1-2

Also some kind of functionality which would allow cygcheck to query
the same files as the web search would be really cool.  Something like
a:

cygcheck --whatprovides /usr/bin/ls.exe

would be really useful.

Another interesting thing would be to do some ntsec/mkpasswd/mkgroup
type sanity checks or even to fix up common ntsec problems.

cgf


Re: Questions and a RFC [was Re: Assignment from Nicholas Wourms arrived]

2003-08-14 Thread Corinna Vinschen
On Wed, Aug 13, 2003 at 11:44:36AM -0400, Nicholas Wourms wrote:
> [EMAIL PROTECTED] wrote:
> >What are you trying to implement?  If you need lstat, you're perhaps better
> >off implementing this in Cygwin instead of newlib.
> 
> ftw/nftw.  Per Gerrit's suggestion on the list, I looked at OpenBSD's 
> version of ftw/nftw they did for the US DOD.  IMHO, it looks the be the 
> most robust compared to the other Non-GPL'ed versions floating around. 
> I suppose one could write it from scratch, but if a reasonable 
> implementation exists, why bother?  Of course to the next point...
> 
> Perhaps it doesn't belong in newlib, as it isn't terribly portable in 
> it's current state.  I basically had to disgorge a bunch of extra code 
> code which was targeted at platforms with a more robust(mature?) 
> opendir().  However, I suppose I could just #if 0 it, and leave it to 
> the linux/ELIX people to fix up the parts which apply to them [1].

Putting ftw into newlib is of course a good way to get rid of the GPL'd
version of ftw and ftw64 in libc/sys/linux.  But it's more work.  You
would have to provide 32 and 64 bit versions as in newlib and I doubt
you will get approval if the function isn't portable enough.

OTOH, I ripped all Cygwin-only code from newlib and moved it into the
cygwin dir a while ago, so if you create a Cygwin-only version of ftw,
you should put it into Cygwin itself.  The advantage would be that you
only have to care for a 64 bit version.

>   Speaking of aliases, about this time last year, 
> Conrad and I were debating the reasoning behind the underscore aliases 
> in cygwin.din.  I speculated that they might be a work around for 
> elf-centric configuration programs which look for weak versions of the 
> symbols (which indeed seems to be the case for argz & the configure 
> found in binutils/gcc/gdb).  He thought that it had something to do with 
> MSVC compatibility.  However, it seems that people have since stopped 
> doing this.  Out of curiosity, what was the history behind doing this? 

Newlib calls all sysfuncs with leading underscore (_open, _close, etc)
since it provides the API versions (open, close) by itself, typically.
Some of the other functions might (dunno, really) be underscored for
msvcrt.dll compatibility.  Actually I guess that most of the other
_foo=foo bla just has been added since "we did it always this way".
In theory it's unnecessary to declare an underscore alias of a function
if newlib never accesses it.  The API defines them w/o underscore so
that should be sufficient.  But we will keep the existing ones in
cygwin.din for backward compatibility, of course.

> For future contributions, what is the official policy on doing it now?

Basically don't add an underscore alias.  Create an underscore alias if
the function is used by newlib.  Or, create an underscore alias if it's
e.g. available in Linux or BSD, which might happen (mempcpy comes to mind).  

> suppose you can be the judge of where it belongs :-D.  I think, though, 
> that I'll wait until post-1.5.x to do this, as it seems to be the 
> consensus that we are in a feature "freeze".

Yeah, and as I said, just create a 64 bit version.  Look into the
implementation of other Cygwin functions like lstat64 for the types
you'll have to use (e.g. _off64_t instead of off_t).

> Speaking of things in the loop, has any further thought been given to 
> David Euresti's patch from last year which enables passing of file 
> descriptors between processes via Unix Domain Sockets?  It'd be a shame 
> not to use it but, alas, David has expressed no further interest in 
> working on it and Conrad (who had intended to pick up the torch) seems 
> to have fallen off the face of the earth.  At one point you said you'd 
> like to see it go in, but it was dependent on David's cooperation.  Is 
> this in the loop or has it been dropped altogether?

The point was this:  David's patch only worked with cygserver and I was
pretty sure that it would be possible to get it also working inside
plain Cygwin.  I began to work on that but I guess I had no fixed concept
so I ran into problems, stopped working on it, were distracted by other
stuff... ye olde story.

I'd still like to see descriptor passing in Cygwin and I still think it's
possible in Cygwin w/o cygserver.  Cygserver intervention should only
be necessary if both processes have nothing to do with each other, which
isn't very likely.  Most of the time it's a parent/child relationship or
at least one of the processes is running under a privileged account.

Unfortunately, while it's no problem to send and receive the handles, it
needs a concept of submitting all fhandler internal information to the
receiving process as well, otherwise the fhandler wouldn't reflect the
actual state of the associated windows handle and the receiving process
would fail to work correctly.  At one point I found out that I'd need
some sort of serializing fhandlers, which was part of Cygwin in older
versions (B20 an

Re: setmetamode

2003-08-14 Thread Corinna Vinschen
On Mon, Jul 28, 2003 at 09:39:53AM +0900, Kazuhiro Fujieda wrote:
> >>> On Fri, 18 Jul 2003 19:10:54 +0200
> >>> Corinna Vinschen <[EMAIL PROTECTED]> said:
> Umm. I can't find any reason why it doesn't work.
> I'd like to confirm whether setmetamode can show and change the
> meta mode in your environment.
> 
> Could you show me the output of the following instructions:
> $ setmetamode
> 
> $ setmetamode meta
> $ setmetamode
> 

$ setmetamode
escprefix
[~]$ cat | od -t x1

000 1b 78 1b 78 1b 78 0d 0a
010
$ setmetamode meta
$ setmetamode
metabit
$ cat | od -t x1

000 1b 78 1b 78 1b 78 0d 0a
010

> > Another question: Shouldn't this also add a sys/kd.h file which just
> > includes ?
> 
> Probably yes. I'm not, however, sure why it is necessary.
> To stick to the way of Linux?

Yes.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Christopher Faylor
On Sun, Aug 10, 2003 at 07:50:41AM +1000, Robert Collins wrote:
>On Sun, 2003-08-10 at 02:12, Christopher Faylor wrote:
>> On Thu, Aug 07, 2003 at 06:50:10PM -0400, Igor Pechtchanski wrote:
>>Also some kind of functionality which would allow cygcheck to query the
>>same files as the web search would be really cool.  Something like a:
>>
>>cygcheck --whatprovides /usr/bin/ls.exe
>>
>>would be really useful.
>
>
>Hmm, I think we're getting into stuff that setup should do itself.  We
>-do- have command line functionality...

Can setup do a:

setup --whatprovides /bin/ls.exe > /tmp/foo

?

I don't see how that will ever be possible given the windows problems with
stdio and GUI apps.  I guess we could make setup a console utility but
that would result in the ugly black console box flashing up whenever
you start setup.exe.

In Red Hat terms, this would be like starting up anaconda (the
installer) every time you want to query RHN.  I don't see how that's
useful.

If the setup library abstraction ever shows up then this would be a
candidate for that.  It is not, IMO, a function for setup itself.

cgf


[PATCH] Consider extensions for special names in managed mode

2003-08-14 Thread Igor Pechtchanski
On Wed, 13 Aug 2003, Ronald Landheer-Cieslak wrote:

> On Tue, Aug 12, 2003 at 01:39:18PM -0400, Igor Pechtchanski wrote:
> > Ronald,
> >
> > I think there might be a bug in the way managed mode figures special
> > filenames.  Try simply "touch aux" instead of "touch aux.x".  If that
> > works, it'll confirm my reading the code.  I'll submit a patch later today
> > if noone beats me to it.
> >   Igor
>
> `touch aux' works like a charm :|
>
> rlc

Yeah.  I promised a patch, didn't I?  *Sigh*.
Igor
==
2003-08-13  Igor Pechtchanski  <[EMAIL PROTECTED]>

* path.cc (special_name): Add checks for some specials
followed by a "." and a FIXME comment.

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton
Index: winsup/cygwin/path.cc
===
RCS file: /cvs/src/src/winsup/cygwin/path.cc,v
retrieving revision 1.262
diff -u -p -r1.262 path.cc
--- winsup/cygwin/path.cc   5 Aug 2003 04:49:44 -   1.262
+++ winsup/cygwin/path.cc   13 Aug 2003 14:16:57 -
@@ -1418,10 +1418,15 @@ special_name (const char *s, int inc = 1
   if (strpbrk (s, special_chars))
 return !strncasematch (s, "%2f", 3);
 
+  // FIXME: add com0 and {com,lpt}N.*
   if (strcasematch (s, "nul")
+  || strncasematch (s, "nul.", 4)
   || strcasematch (s, "aux")
+  || strncasematch (s, "aux.", 4)
   || strcasematch (s, "prn")
+  || strncasematch (s, "prn.", 4)
   || strcasematch (s, "con")
+  || strncasematch (s, "con.", 4)
   || strcasematch (s, "conin$")
   || strcasematch (s, "conout$"))
 return -1;


Re: [PATCH]: Add some interoperability macros to sys/param.h

2003-08-14 Thread Corinna Vinschen
On Thu, Aug 07, 2003 at 03:23:51PM -0400, Nicholas Wourms wrote:
> 2003-08-07  Nicholas Wourms  <[EMAIL PROTECTED]>
> 
> * include/sys/param.h (setbit): Add new bitmap related macro.
> (clrbit): Likewise.
> (isset): Likewise.
> (isclr): Likewise.
> (howmany): Add new counting/rounding macro.
> (rounddown): Likewise.
> (roundup): Likewise.
> (roundup2): Likewise.
> (powerof2): Likewise
> (MIN): Add macro for calculating min.
> (MAX): Add macro for calculating max.

Applied.  I've just added a NBBY definition.

Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


[PATCH] pwdgrp::read_group(): Don't call free() twice with the same address

2003-08-14 Thread David Rothenberger
Hi,

This patch avoids the heap corruption that was causing the problem
described in
.

In pwdgrp::read_group(), there is loop to free allocated gr_mem
buffers.  That loop checks to see if gr_mem != &null_ptr, but does
not set gr_mem to &null_ptr after free() is called.  Subsequent
calls then attempt to free the same address again, corrupting the
malloc structures.

The tar test case triggers this behavior if there is no /etc
directory available, for some reason.

Dave

==
ChangeLog:
2003-08-08  David Rothenberger  <[EMAIL PROTECTED]>

* grp.cc (read_group): Set __group32.gr_mem pointer back to
&null_ptr after free() is called.

Index: cygwin/grp.cc
===
RCS file: /cvs/src/src/winsup/cygwin/grp.cc,v
retrieving revision 1.81
diff -u -u -p -r1.81 grp.cc
--- cygwin/grp.cc   30 Jun 2003 13:07:36 -  1.81
+++ cygwin/grp.cc   8 Aug 2003 18:29:44 -
@@ -75,7 +75,10 @@ pwdgrp::read_group ()
 {
   for (int i = 0; i < gr.curr_lines; i++)
 if ((*group_buf)[i].gr_mem != &null_ptr)
-  free ((*group_buf)[i].gr_mem);
+  {
+free ((*group_buf)[i].gr_mem);
+(*group_buf)[i].gr_mem = &null_ptr;
+  }
 
   load ("/etc/group");
 


[PATCH]: Add some interoperability macros to sys/param.h

2003-08-14 Thread Nicholas Wourms
Hi,

This patch adds 11 new macros to Cygwin's sys/param.h.  They include:

setbit(a,i)
clrbit(a,i)
isset(a,i)
isclr(a,i)
howmany(x, y)
rounddown(x, y)
roundup(x, y)
roundup2(x, y)
powerof2(x)
MIN(a,b)
MAX(a,b)
I find some to be very useful for many mundane routines (esp. MIN/MAX). 
 It should be noted that I chose to add all 11 of them (as opposed to 
just the ones I use) because this subset of macros seems to be common 
across all *bsd and linux distributions.  In doing so we improve our 
interoperability and make porting easier.  Although I "peeked" at the 
param.h header on my linux box to see if they were all defined, the 
macros I used were copied verbatim from the freebsd cvs 
src/sys/sys/param.h.  Furthermore, I didn't actually check the 
definition expression in the linux header, so I feel confident that I 
have violated no licenses.  I have an assignment pending, but I was 
hoping this change would be small enough to go in before then.

Cheers,
Nicholas
2003-08-07  Nicholas Wourms  <[EMAIL PROTECTED]>

* include/sys/param.h (setbit): Add new bitmap related macro.
(clrbit): Likewise.
(isset): Likewise.
(isclr): Likewise.
(howmany): Add new counting/rounding macro.
(rounddown): Likewise.
(roundup): Likewise.
(roundup2): Likewise.
(powerof2): Likewise
(MIN): Add macro for calculating min.
(MAX): Add macro for calculating max.
Index: cygwin/include/sys/param.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/sys/param.h,v
retrieving revision 1.2
diff -u -3 -p -r1.2 param.h
--- cygwin/include/sys/param.h  30 May 2003 08:39:02 -  1.2
+++ cygwin/include/sys/param.h  7 Aug 2003 17:03:14 -
@@ -53,4 +53,23 @@
 #define NULL0L
 #endif
 
+/* Bit map related macros. */
+#definesetbit(a,i) ((a)[(i)/NBBY] |= 1<<((i)%NBBY))
+#defineclrbit(a,i) ((a)[(i)/NBBY] &= ~(1<<((i)%NBBY)))
+#defineisset(a,i)  ((a)[(i)/NBBY] & (1<<((i)%NBBY)))
+#defineisclr(a,i)  (((a)[(i)/NBBY] & (1<<((i)%NBBY))) == 0)
+
+/* Macros for counting and rounding. */
+#ifndef howmany
+#definehowmany(x, y)   (((x)+((y)-1))/(y))
+#endif
+#definerounddown(x, y) (((x)/(y))*(y))
+#defineroundup(x, y)   x)+((y)-1))/(y))*(y))  /* to any y */
+#defineroundup2(x, y)  (((x)+((y)-1))&(~((y)-1))) /* if y is powers of two */
+#define powerof2(x)x)-1)&(x))==0)
+
+/* Macros for min/max. */
+#defineMIN(a,b)(((a)<(b))?(a):(b))
+#defineMAX(a,b)(((a)>(b))?(a):(b))
+


Re: Questions and a RFC [was Re: Assignment from Nicholas Wourmsarrived]

2003-08-14 Thread Nicholas Wourms
[EMAIL PROTECTED] wrote:
Nicholas Wourms wrote:

Planning ahead for future possibilities is always a good thing, so in 
that respect this seems like a sound idea.  Since we are already 
dealing with ABI breakage, I thought I'd float this now to see what 
people think.  Would a change like this be of benefit to Cygwin?


Hell no.  I am irrevocably and unalterably opposed to implementing this 
change before 1.5.2 goes gold.

We've already had THREE ABI breakages in the last month.  Now, you want 
to add another one -- to avoid one in the future.

Here's an idea:  lets wait until the NEXT scheduled ABI breakage to do 
yours; then we'll get two for the price of one.

Right now, cygwin-1.5.x is overdue by several months.  It NEEDS to go 
out the door; we can continually add more ABI breakages forever and 
never release a new version...but that's rather silly IMO.
That's perfectly fine with me, you point is well made.

Cheers,
Nicholas


Re: Questions and a RFC [was Re: Assignment from Nicholas Wourmsarrived]

2003-08-14 Thread Nicholas Wourms
[EMAIL PROTECTED] wrote:

On Tue, Aug 12, 2003 at 06:55:11PM -0400, Nicholas Wourms wrote:

1)Did my MUA strip the tabs from the patch?  The only reason I ask is 


Yes.  The patch already contained spaces.  I see you're using Mozilla/NS7
so I'm wondering how this happened.  AFAIK, Mozilla doesn't touch
attachments.
Alas, I fear that NS7.1(aka Moz 1.4) is having the same problem folks 
were having on the LKML with 1.4...  I think the work around was to send 
formatted attachments as .txt so that Moz would get the mime-type right. 
 I'll send a clean up patch with a clarifying comment for NBBY to test 
this theory.

No :-)

Long answer:  You don't need any assignment for newlib due to the relaxed
licensing of newlib.
Excellent.


3)I'm still trying to figure out how to use lstat in newlib source code, 


What are you trying to implement?  If you need lstat, you're perhaps better
off implementing this in Cygwin instead of newlib.
ftw/nftw.  Per Gerrit's suggestion on the list, I looked at OpenBSD's 
version of ftw/nftw they did for the US DOD.  IMHO, it looks the be the 
most robust compared to the other Non-GPL'ed versions floating around. 
I suppose one could write it from scratch, but if a reasonable 
implementation exists, why bother?  Of course to the next point...

Perhaps it doesn't belong in newlib, as it isn't terribly portable in 
it's current state.  I basically had to disgorge a bunch of extra code 
code which was targeted at platforms with a more robust(mature?) 
opendir().  However, I suppose I could just #if 0 it, and leave it to 
the linux/ELIX people to fix up the parts which apply to them [1].


since apparently the function declaration is hidden when building 
newlib/cygwin.  So far, any attempt to use it results in undefined 
references to _lstat when linking the dll.  I tried adding a definition 
to _syslist.h, but that didn't work.  I hate to sound clueless, but if 
someone could nudge me toward the right header or magic, that would be 
great.


cd winsup/cygwin
ctags -R .
vi -t cygwin_lstat
However, thinking about this situation, I'm sure it wasn't really clever
to rename lstat to cygwin_lstat.  Your problem to link against it stems
from that fact and other declaration problems has been easilier solved by
just adding a bunch of defines at the top of syscalls.cc.
*Doh*  I didn't connect the dots on that one, thanks for the 
clarification :-).  Speaking of aliases, about this time last year, 
Conrad and I were debating the reasoning behind the underscore aliases 
in cygwin.din.  I speculated that they might be a work around for 
elf-centric configuration programs which look for weak versions of the 
symbols (which indeed seems to be the case for argz & the configure 
found in binutils/gcc/gdb).  He thought that it had something to do with 
MSVC compatibility.  However, it seems that people have since stopped 
doing this.  Out of curiosity, what was the history behind doing this? 
For future contributions, what is the official policy on doing it now?

[...time passes...]

Ok, I've tested to revert the function name from cygwin_lstat to lstat
in syscalls.cc and applied the appropriate patch.  This is transparent
to all applications and should allow to use lstat from newlib as in
libc/sys/linux.
Thank you, I will submit some code later on for review.  At that time, I 
suppose you can be the judge of where it belongs :-D.  I think, though, 
that I'll wait until post-1.5.x to do this, as it seems to be the 
consensus that we are in a feature "freeze".

4)Corinna, I've been working on porting some of the missing 
SUSv3/c99/bsd functions from the *bsd libc.  I noticed that the libutil 
which you distribute with inetutils contains some of the functions I 
thought belonged in libc, or at least the headers of newlib would have 
me believe this.  Specifically, I was wanted to work on adding instances of:
endusershell()
setusershell()
getusershell()
ruserok()
iruserok()


Don't do this(TM).  The reason is that, first, I have already code for
this in the loop and, second, I have to coordinate this with changing
my inetutils package not to contain the libutil.a anymore at one point.
I appreciate your effort but I'd like to keep these functions in my
hand, even though it might take a bit longer.
No problem, I didn't know what the story was, which is why I was testing 
the waters before investing any more effort/time.  By all means, I'll 
look at other things to work on, no worries.

Speaking of things in the loop, has any further thought been given to 
David Euresti's patch from last year which enables passing of file 
descriptors between processes via Unix Domain Sockets?  It'd be a shame 
not to use it but, alas, David has expressed no further interest in 
working on it and Conrad (who had intended to pick up the torch) seems 
to have fallen off the face of the earth.  At one point you said you'd 
like to see it go in, but it was dependent on David's cooperation.  Is 
this in the loop or has it been 

Re: [PATCH] Consider extensions for special names in managed mode

2003-08-14 Thread Corinna Vinschen
On Wed, Aug 13, 2003 at 10:19:08AM -0400, Igor Pechtchanski wrote:
> 2003-08-13  Igor Pechtchanski  <[EMAIL PROTECTED]>
> 
>   * path.cc (special_name): Add checks for some specials
>   followed by a "." and a FIXME comment.

Ok, I've applied it.  I guess Chris can work from that, too.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


Re: [PATCH] Consider extensions for special names in managed mode

2003-08-14 Thread Corinna Vinschen
On Wed, Aug 13, 2003 at 10:19:08AM -0400, Igor Pechtchanski wrote:
> Yeah.  I promised a patch, didn't I?  *Sigh*.
>   Igor
> ==
> 2003-08-13  Igor Pechtchanski  <[EMAIL PROTECTED]>
> 
>   * path.cc (special_name): Add checks for some specials
>   followed by a "." and a FIXME comment.

I leave this to Chris for obvious reasons.

> +  // FIXME: add com0 and {com,lpt}N.*
>if (strcasematch (s, "nul")
> +  || strncasematch (s, "nul.", 4)
>|| strcasematch (s, "aux")
> +  || strncasematch (s, "aux.", 4)
>|| strcasematch (s, "prn")
> +  || strncasematch (s, "prn.", 4)
>|| strcasematch (s, "con")
> +  || strncasematch (s, "con.", 4)
>|| strcasematch (s, "conin$")
>|| strcasematch (s, "conout$"))
>  return -1;

Clueless question:  What about sth. like foo.aux?

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


Re: stdint.h define of INT32_MIN

2003-08-14 Thread Gerrit P. Haase
Hallo Christopher,

Am Freitag, 8. August 2003 um 21:31 schriebst du:

>>Hallo ,

> "Hello"

I'm german;)

[...]

> I've applied the above patch.

Thank you.


Gerrit
-- 
=^..^=



Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Robert Collins
On Sun, 2003-08-10 at 10:12, Christopher Faylor wrote:


> I don't see how that will ever be possible given the windows problems with
> stdio and GUI apps.  I guess we could make setup a console utility but
> that would result in the ugly black console box flashing up whenever
> you start setup.exe.

I was thinking of something like 'cygsetup' a console only version.
cygcheck could then call that for the setup-related stuff it does now,
and these extra features.

We still have teasing apart of the GUI and logic components to finish
before this becomes easy to do...


Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Christopher Faylor
On Sat, Aug 09, 2003 at 12:12:11PM -0400, Christopher Faylor wrote:
>On Thu, Aug 07, 2003 at 06:50:10PM -0400, Igor Pechtchanski wrote:
>>Hi,
>>
>>This patch adds most of the capability of the script from
>> to cygcheck.
>>It is triggered by the "-c" flag to cygcheck.  "Integrity" is a rather
>>strong word, actually, as all this checks for is the existence of files
>>and directories, but this could be further built upon (for example, tar
>>has a diff option that could be useful).  The patch is against cvs HEAD
>>with my previous micropatch
>>() applied.
>>Comments and suggestions welcome.
>
>I'm getting some odd errors when I apply this patch:
>
>"4NT: Unknown command f:"
>
>(as you can see I use 4NT).
>
>I haven't had time to debug where these are coming from but I get one
>for every file displayed.

The enclosed patch fixes that.

I'll check this in but it would be nice if (WBNI) this used a mingw gzip
library rather than calling gzip directly.  That's a fair amount of
work but I could resurrect the zlib library in winsup if necessary.

I wonder why setup is using gzip rather than bzip2 for the package files...

cgf

--- dump_setup.cc~  2003-08-07 21:42:02.0 -0400
+++ dump_setup.cc   2003-08-09 12:16:39.658996759 -0400
@@ -242,6 +242,8 @@ check_package_files (int verbose, char *
   strcat(strcat(filelist, package), ".lst.gz");
   char *zcat = cygpath("/bin/gzip.exe", NULL);
   char command[4096];
+  while (char *p = strchr (zcat, '/'))
+*p = '\\';
   strcat(strcpy(command, zcat), filelist);
   FILE *fp = popen (command, "rt");
   char buf[4096];


Re: [PATCH] Checking integrity of installed packages in cygcheck

2003-08-14 Thread Igor Pechtchanski
On Sat, 9 Aug 2003, Christopher Faylor wrote:

> On Sat, Aug 09, 2003 at 12:12:11PM -0400, Christopher Faylor wrote:
> >On Thu, Aug 07, 2003 at 06:50:10PM -0400, Igor Pechtchanski wrote:
> >>Hi,
> >>
> >>This patch adds most of the capability of the script from
> >> to cygcheck.
> >>It is triggered by the "-c" flag to cygcheck.  "Integrity" is a rather
> >>strong word, actually, as all this checks for is the existence of files
> >>and directories, but this could be further built upon (for example, tar
> >>has a diff option that could be useful).  The patch is against cvs HEAD
> >>with my previous micropatch
> >>() applied.
> >>Comments and suggestions welcome.
> >
> >I'm getting some odd errors when I apply this patch:
> >
> >"4NT: Unknown command f:"
> >
> >(as you can see I use 4NT).
> >
> >I haven't had time to debug where these are coming from but I get one
> >for every file displayed.
>
> The enclosed patch fixes that.
>
> I'll check this in but it would be nice if (WBNI) this used a mingw gzip
> library rather than calling gzip directly.  That's a fair amount of
> work but I could resurrect the zlib library in winsup if necessary.
>
> I wonder why setup is using gzip rather than bzip2 for the package files...
>
> cgf
>
> --- dump_setup.cc~2003-08-07 21:42:02.0 -0400
> +++ dump_setup.cc 2003-08-09 12:16:39.658996759 -0400
> @@ -242,6 +242,8 @@ check_package_files (int verbose, char *
>strcat(strcat(filelist, package), ".lst.gz");
>char *zcat = cygpath("/bin/gzip.exe", NULL);
>char command[4096];
> +  while (char *p = strchr (zcat, '/'))
> +*p = '\\';
>strcat(strcpy(command, zcat), filelist);
>FILE *fp = popen (command, "rt");
>char buf[4096];

Oops, sorry, I should have added that I only tested that patch on Win2k...
As for the mingw zlib library, is it already a requirement for building
Cygwin?  If not, I'd be very reluctant to make it one...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton



[PATCH] readdir (): Do not set 'errno' if end of dir is encountered

2003-08-14 Thread Pavel Tsekov
Hello,

Attached is a patch + a testcase. The testcase can be executed with any of
the
following directories:

  /cygdrive
  /proc
  /proc/
  /proc/registry/HKEY_WHATEVER

2003-08-05  Pavel Tsekov  <[EMAIL PROTECTED]>

* fhandler_disk_file.cc (fhandler_cygdrive::readdir): Do not change 'errno'
if
end of directory condition is encountered as per SUSv2.
* fhandler_proc.cc (fhandler_proc::readdir): Ditto.
* fhandler_process (fhandler_process::readdir): Ditto.
* fhandler_registry (fhandler_registry::readdir): Ditto.

Pavel

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post

scandir.c
Description: Binary data
Index: fhandler_disk_file.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_disk_file.cc,v
retrieving revision 1.58
diff -u -p -r1.58 fhandler_disk_file.cc
--- fhandler_disk_file.cc   26 Jul 2003 04:53:59 -  1.58
+++ fhandler_disk_file.cc   5 Aug 2003 02:38:36 -
@@ -769,10 +769,7 @@ fhandler_cygdrive::readdir (DIR *dir)
   if (!iscygdrive_root ())
 return fhandler_disk_file::readdir (dir);
   if (!pdrive || !*pdrive)
-{
-  set_errno (ENMFILE);
-  return NULL;
-}
+return NULL;
   else if (dir->__d_position > 1
   && GetFileAttributes (pdrive) == INVALID_FILE_ATTRIBUTES)
 {
Index: fhandler_proc.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_proc.cc,v
retrieving revision 1.34
diff -u -p -r1.34 fhandler_proc.cc
--- fhandler_proc.cc26 Jul 2003 04:53:59 -  1.34
+++ fhandler_proc.cc5 Aug 2003 02:38:39 -
@@ -206,7 +206,6 @@ fhandler_proc::readdir (DIR * dir)
dir->__d_position++;
return dir->__d_dirent;
  }
-  set_errno (ENMFILE);
   return NULL;
 }
 
Index: fhandler_process.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_process.cc,v
retrieving revision 1.35
diff -u -p -r1.35 fhandler_process.cc
--- fhandler_process.cc 9 Jul 2003 01:33:06 -   1.35
+++ fhandler_process.cc 5 Aug 2003 02:38:42 -
@@ -147,10 +147,7 @@ struct dirent *
 fhandler_process::readdir (DIR * dir)
 {
   if (dir->__d_position >= PROCESS_LINK_COUNT)
-{
-  set_errno (ENMFILE);
-  return NULL;
-}
+return NULL;
   strcpy (dir->__d_dirent->d_name, process_listing[dir->__d_position++]);
   syscall_printf ("%p = readdir (%p) (%s)", &dir->__d_dirent, dir,
  dir->__d_dirent->d_name);
Index: fhandler_registry.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_registry.cc,v
retrieving revision 1.19
diff -u -p -r1.19 fhandler_registry.cc
--- fhandler_registry.cc16 Jun 2003 03:24:10 -  1.19
+++ fhandler_registry.cc5 Aug 2003 02:38:45 -
@@ -331,7 +331,8 @@ retry:
 {
   RegCloseKey ((HKEY) dir->__d_u.__d_data.__handle);
   dir->__d_u.__d_data.__handle = INVALID_HANDLE_VALUE;
-  seterrno_from_win_error (__FILE__, __LINE__, error);
+  if (error != ERROR_NO_MORE_ITEMS)
+   seterrno_from_win_error (__FILE__, __LINE__, error);
   goto out;
 }