Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E398E01.F62E2163@phekda.freeserve.co.uk>
Date: Thu, 30 Jan 2003 20:41:37 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Take on __solve_symlinks()
References: <3E286C07 DOT 7040200 AT mif DOT vu DOT lt> <3E2943DA DOT 523770FC AT phekda DOT freeserve DOT co DOT uk> <3E297258 DOT 50906 AT mif DOT vu DOT lt> <3E2A9396 DOT EF36FE73 AT phekda DOT freeserve DOT co DOT uk> <3E305DAB DOT 8090607 AT mif DOT vu DOT lt> <3E305D5A DOT 16693047 AT phekda DOT freeserve DOT co DOT uk> <3E386A1C DOT 9050303 AT mif DOT vu DOT lt> <3E3940F9 DOT A66C7217 AT phekda DOT freeserve DOT co DOT uk> <3E39880C DOT 4060607 AT mif DOT vu DOT lt>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Laurynas Biveinis wrote:
[snip]
> Very interesting, given that the first thing __solve_symlink does is to
> copy __symlink_path to __real_path. I don't see how this patch could
> make any difference, and it doesn't at my sandbox. The testcase gives
> correct results both ways. I strongly suspect that we are testing two
> different versions of __solve_symlinks... Maybe you could try copy
> somewhere the directory with testsuite sources, copy here up to the date
> CVS version of __solve_symlinks and add it to makefile ?

I've just tried building with another CVS that has _no_ source changes and
only changes to the Cygnus test suite (C++ build fixes). I just did a 'cvs
update -dA', so it has your latest check-in for xsymlink.c ("Rearrange symlink
loop detection"). This is my "reference" read-only tree. The test fails there
too.

> Secondly, the only potential point of failure in this testcase with
> current __solve_symlinks version is a call to
> __internal_readlink("c:../../../../../djgpp.204/tests/libc/compat/unistd/test1")
> from the last repetition of main __solve_symlinks loop (with end pointer
> pointing at '\0'). This call works for me, it seems that
> __internal_readlink deals with too many /../../ correctly. Could you see
> what happens at your side (in the case we have identical
> __solve_symlinks() sources)

The failing path has six ".."s on my system. The path with five ".."s works,
because it does "try" to go above the root directory. Perhaps there is a typo
in the text above?

Anyway, findfirst() fails on this:

    c:../../../../../../djgpp.204/tests/libc/compat/unistd/test1

which causes __internal_readlink() to fail with ENOENT, which causes
__solve_symlinks() to return the unresolved path (NB: test1 is a symlink to
file1).

I am wondering if there is some difference in the behaviour of findfirst() on
our systems. I am running Windows '98 SE:

Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\WINDOWS>ver

Windows 98 [Version 4.10.2222]

Which OS are you using?

bash-2.04$ pwd
c:/djgpp.204/rdawe-test/findfirst
bash-2.04$ ./fftest.exe ../../../autoexec.bat
../../../autoexec.bat -> ../../../autoexec.bat
../../../autoexec.bat: matched
bash-2.04$ ./fftest.exe ../../../../autoexec.bat
../../../../autoexec.bat -> ../../../../autoexec.bat
../../../../autoexec.bat: unmatched

Try the test program at the end of this mail - fftest.c.

[snip]
> >>BTW, I wonder if we could do something like SUBST does at runtime...
> >
> >
> > What would you do, if we could?
> 
> Then we could create a virtual drive on the fly for the testsuite and
> destroy afterwards. No 'insert blank floppy' stuf...

Ah, I thought you meant __solve_symlinks could do something clever with
SUBST-ituted drives. Your virtual floppy idea makes much more sense...

Perhaps you could write a batch file or shell script that looks for a free
drive letter, runs SUBST and then passes the drive letter to the xsymlink
test? Afterward it would un-SUBST the drive. This would not rely on knowing
how SUBST works.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

---Start fftest.c---
#include <stdio.h>
#include <stdlib.h>
#include <dir.h>
#include <dpmi.h>
#include <go32.h>
#include <libc/dosio.h>

int
main (int argc, char *argv[])
{
  char buf[FILENAME_MAX];
  struct ffblk foo;

  if (argc < 2)
    {
      puts("No filename given");
      return(EXIT_FAILURE);
    }

  _put_path(argv[1]);
  dosmemget(__tb, sizeof(buf), buf);

  printf("%s -> %s\n", argv[1], buf);

  printf("%s: %s\n",
	 argv[1],
	 findfirst(argv[1], &foo, 0) == 0 ? "matched" : "unmatched");

  return(EXIT_SUCCESS);
}
---End fftest.c---