Re: d_ino bug in //

2006-02-28 Thread Corinna Vinschen
On Feb 27 18:18, Eric Blake wrote:
  
  It looks like Corinna already nailed the issue, but for the
  archive's sake, my complaint was that under //, d_ino and
  st_ino did not match properly.  With the 20060227 snapshot
  (or whenever the next one is), the same test program
  should now output:
 
 Other directories that may have the same problem, as detected
 by my local build of pwd:
 
 $ cd /proc/registry/HKEY_LOCAL_MACHINE/
 $ ~/pwd
 /home/eblake/pwd: couldn't find directory entry in `..' with matching i-node
 $ cd /proc/self/fd
 $ ~/pwd
 /home/eblake/pwd: couldn't find directory entry in `..' with matching i-node
 $

Should be fixed now.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/



d_ino bug in //

2006-02-27 Thread Eric Blake
It looks like d_ino is not being correctly populated within //.
Running the program below on snapshot 20060220 produced:

$ ./foo
Searching for //eblake, inode 10556217422951964268
entry 553: name match only (inode 14394969718775064264)
2098 entries processed
$ cat foo.c
#include stdio.h
#include dirent.h
#include sys/stat.h
#include errno.h
#include unistd.h
#include string.h

#define DEFAULT_SHARE eblake

int main(int argc, char**argv)
{
   ino_t ino;
   struct stat sb;
   DIR *dirp;
   int i = 0;

   switch (argc)
   {
   case 1:
  argv[1] = DEFAULT_SHARE;
  break;
   case 2:
  break;
   default:
  printf(Usage: foo [sharename]\n
   Search // for sharename\n);
  return 1;
   }

   if (chdir(//)  0)
   {
  printf(chdir failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   if (lstat(argv[1], sb)  0)
   {
  printf(lstat failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   ino = sb.st_ino;
   printf(Searching for //%s, inode %llu\n, argv[1], ino);
   if ((dirp = opendir (..)) == NULL)
   {
  printf(opendir failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   while (1)
   {
  struct dirent *dp;

  errno = 0;
  i++;
  if ((dp = readdir (dirp)) == NULL)
  {
 if (errno)
 {
printf(opendir failed: %d %s\n, errno, strerror(errno));
return 2;
 }
 else
break;
  }
  if (ino == dp-d_ino)
  {
 if (strcasecmp(argv[1], dp-d_name) == 0)
 {
printf(match found at entry %d\n, i);
 }
 else
 {
printf(entry %d: inode match only (name %s)\n, i, dp-d_name);
 }
  }
  else if (strcasecmp(argv[1], dp-d_name) == 0)
  {
 printf(entry %d: name match only (inode %llu)\n, i, dp-d_ino);
  }
   }
   printf(%d entries processed\n, i);
   if (closedir (dirp)  0)
   {
  printf(closedir failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   return 0;
}

-- 
Eric Blake


--
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/



Re: d_ino bug in //

2006-02-27 Thread Christopher Faylor
On Mon, Feb 27, 2006 at 05:22:57PM +, Eric Blake wrote:
It looks like d_ino is not being correctly populated within //.
Running the program below on snapshot 20060220 produced:

A (somewhat) simple test case (patent pending) is nice but it really
should be accompanied with an explanation of the problem.  How about
describing *in words* what you think is broken?

cgf

$ ./foo
Searching for //eblake, inode 10556217422951964268
entry 553: name match only (inode 14394969718775064264)
2098 entries processed
$ cat foo.c
#include stdio.h
#include dirent.h
#include sys/stat.h
#include errno.h
#include unistd.h
#include string.h

#define DEFAULT_SHARE eblake

int main(int argc, char**argv)
{
   ino_t ino;
   struct stat sb;
   DIR *dirp;
   int i = 0;

   switch (argc)
   {
   case 1:
  argv[1] = DEFAULT_SHARE;
  break;
   case 2:
  break;
   default:
  printf(Usage: foo [sharename]\n
   Search // for sharename\n);
  return 1;
   }

   if (chdir(//)  0)
   {
  printf(chdir failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   if (lstat(argv[1], sb)  0)
   {
  printf(lstat failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   ino = sb.st_ino;
   printf(Searching for //%s, inode %llu\n, argv[1], ino);
   if ((dirp = opendir (..)) == NULL)
   {
  printf(opendir failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   while (1)
   {
  struct dirent *dp;

  errno = 0;
  i++;
  if ((dp = readdir (dirp)) == NULL)
  {
 if (errno)
 {
printf(opendir failed: %d %s\n, errno, strerror(errno));
return 2;
 }
 else
break;
  }
  if (ino == dp-d_ino)
  {
 if (strcasecmp(argv[1], dp-d_name) == 0)
 {
printf(match found at entry %d\n, i);
 }
 else
 {
printf(entry %d: inode match only (name %s)\n, i, dp-d_name);
 }
  }
  else if (strcasecmp(argv[1], dp-d_name) == 0)
  {
 printf(entry %d: name match only (inode %llu)\n, i, dp-d_ino);
  }
   }
   printf(%d entries processed\n, i);
   if (closedir (dirp)  0)
   {
  printf(closedir failed: %d %s\n, errno, strerror(errno));
  return 1;
   }
   return 0;
}

--
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/



Re: d_ino bug in //

2006-02-27 Thread Corinna Vinschen
On Feb 27 17:22, Eric Blake wrote:
 It looks like d_ino is not being correctly populated within //.
 Running the program below on snapshot 20060220 produced:
 
 $ ./foo
 Searching for //eblake, inode 10556217422951964268
 entry 553: name match only (inode 14394969718775064264)
 2098 entries processed

I've applied a fix.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/



Re: d_ino bug in //

2006-02-27 Thread Eric Blake
 It looks like d_ino is not being correctly populated within //.
 Running the program below on snapshot 20060220 produced:
 
 A (somewhat) simple test case (patent pending) is nice but it really
 should be accompanied with an explanation of the problem.  How about
 describing *in words* what you think is broken?

It looks like Corinna already nailed the issue, but for the
archive's sake, my complaint was that under //, d_ino and
st_ino did not match properly.  With the 20060227 snapshot
(or whenever the next one is), the same test program
should now output:

Searching for //eblake, inode 10556217422951964268
match found at entry 553

-- 
Eric Blake

--
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/



Re: d_ino bug in //

2006-02-27 Thread Christopher Faylor
On Mon, Feb 27, 2006 at 05:58:50PM +, Eric Blake wrote:
 It looks like d_ino is not being correctly populated within //.
 Running the program below on snapshot 20060220 produced:
 
 A (somewhat) simple test case (patent pending) is nice but it really
 should be accompanied with an explanation of the problem.  How about
 describing *in words* what you think is broken?

It looks like Corinna already nailed the issue, but for the archive's
sake, my complaint was that under //, d_ino and st_ino did not match
properly.

Thanks for the explanation.

It would really be nice (tm) if we had someone devoted to developing test
suite applications for testing these type of things so that we could be
assured of no regressions.

Anyone interested in being the test suite go-to person?

cgf

--
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/



Re: d_ino bug in //

2006-02-27 Thread Eric Blake
 
 It looks like Corinna already nailed the issue, but for the
 archive's sake, my complaint was that under //, d_ino and
 st_ino did not match properly.  With the 20060227 snapshot
 (or whenever the next one is), the same test program
 should now output:

Other directories that may have the same problem, as detected
by my local build of pwd:

$ cd /proc/registry/HKEY_LOCAL_MACHINE/
$ ~/pwd
/home/eblake/pwd: couldn't find directory entry in `..' with matching i-node
$ cd /proc/self/fd
$ ~/pwd
/home/eblake/pwd: couldn't find directory entry in `..' with matching i-node
$

-- 
Eric Blake

--
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/



Re: d_ino bug in //

2006-02-27 Thread Jerry D. Hedden
On Feb 27 17:22, Eric Blake wrote:
 It looks like d_ino is not being correctly populated within //.

Corinna Vinschen replied:
 I've applied a fix.

I tried the fix in the 20060227 snapshot.
It did not fix the 'pwd' problems I noted in:
http://cygwin.com/ml/cygwin/2006-02/msg00933.html

(If it wasn't meant to, then please pardon my ignorance.)


--
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/



Re: d_ino bug in //

2006-02-27 Thread Christopher Faylor
On Mon, Feb 27, 2006 at 01:47:35PM -0700, Jerry D. Hedden wrote:
On Feb 27 17:22, Eric Blake wrote:
 It looks like d_ino is not being correctly populated within //.

Corinna Vinschen replied:
 I've applied a fix.

I tried the fix in the 20060227 snapshot.
It did not fix the 'pwd' problems I noted in:
http://cygwin.com/ml/cygwin/2006-02/msg00933.html

(If it wasn't meant to, then please pardon my ignorance.)

Eric said That is not a cygwin bug so absent any new information, you
shouldn't expect a cygwin snapshot to fix the problem.

cgf

--
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/



Re: d_ino bug in //

2006-02-27 Thread Eric Blake
 Corinna Vinschen replied:
  I've applied a fix.
 
 I tried the fix in the 20060227 snapshot.
 It did not fix the 'pwd' problems I noted in:
 http://cygwin.com/ml/cygwin/2006-02/msg00933.html
 
 (If it wasn't meant to, then please pardon my ignorance.)

There were two sets of bugs - one in cygwin1.dll (which is
now fixed in //, but still broken in /proc/registry and /proc/self),
and one in coreutils pwd.c (which is fixed on my local hard
drive, but is not yet packaged as coreutils-5.94-4).
Give me a bit more time; I hope to have the updated
experimental package out by tomorrow.

Meanwhile, I recommend sticking with coreutils-5.94-1
in production environments (my disclaimer that 5.94-3
is experimental still holds true).

-- 
Eric Blake

--
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/