X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
Message-ID:	<409A4627.6070101@ujf-grenoble.fr>
Date:	Thu, 06 May 2004 16:05:27 +0200
From:	Maurice Lombardi <Maurice DOT Lombardi AT ujf-grenoble DOT fr>
User-Agent:	Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language:	fr-fr, it, en
MIME-Version:	1.0
To:	djgpp <djgpp AT delorie DOT com>
Subject:	Re: another bug in symlinks in 2.04 beta 1 (or alpha 2)

I think I have found a solution: see at end

 >Andrew Cottrell

 >> Maurice Lombardi

 >>C:\work> cat /work/test/titi
 >>c:/djgpp/bin/cat.exe: /work/test/titi: No such file or directory (ENOENT)
 >>
 >>??? problem arises (AFAICS) only when trying to resolve the symlink with
 >>an absolute path, i.e. starting with a slash (or backslash), but without drive letter,
 >>and issuing the command from a directory other than the one in which is
 >>the symlink.
 >>It is not related to cat. I found it first in a makefile. Make was not able
 >>to find a target file by resolving a symlink. The problem did not appear
 >>beforehand with djgpp 2.03 where "ln -s" was replaced by "cp -p" by configure

 >I have seen this a long long time ago if I remember correctly, but it
 >was now so far back I cannot rememebr the exact issue.

 >Some thigs to try:-
 >1) Grep you exe files in the bin directory to ensure that they have
 >"2.04" text in them and if they do not then they may be 2.03. Don't
 >mix 2.03 and 2.04

Done: no problem

 >2) Search the DJGPP workers achive for "Andrew Cottrell" and GCC (I
 >think), then try to find the problem. This is a long shot.

See at end (*)

 >3) If you are not using Make 3.80 give it a try.
I use it (contained in the beta 1 release)

 >>Hope this helps
 >Thanks for this. I do not have access to Win 98 anymore at home or
 >very much time to try to find the problem so could you please try the
 >following and respond with the answers:-

 >1) If you use back slash "\" instead of forward slashes "/" does
 >anything change? I would expect this to fail.

No change between / and \

 >2) Does cat \<filename> work okay? There are a few bugs with various
 >versions of File Utils.

it works

 >3) Which version of File Utils are you using?

fil41b GNU Fileutils 4.1 for DJGPP 2.x, release 2 (binaries)
(from the manifest file fil41b.ver)

 >More questions:-
 >1) What are you trying to build?
GNU Pascal compiler (gpc)

(*) I have found the thread
http://www.delorie.com/djgpp/mail-archives/thread.cgi?msg=djgpp-workers/2003/02/08/23:50:22
they discuss about a test program given in
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2003/01/18/09:26:58
but to run it, it needs a set of directories, files and links which is not given

While looking around I have found in libc sources a test program for solving symlinks
C:\djgpp\src\libc\compat\unistd\xsymlink.txh
namely

#include <libc/symlink.h>
#include <stdio.h>

int main(void)
{
   const char fn[] = "c:/somedir/somelink";
   char file_name[FILENAME_MAX];

   __solve_symlinks(fn, file_name);
   printf("File %s is really %s\n", fn, file_name);
   return 0;
}

running this programs in an idependent directory with various fn[] I obtain

fn = "c:/work/test/titi"
File c:/work/test/titi is really c:/work/test/../toto

fn = "/work/test/titi"
File /work/test/titi is really ../toto

This explains what we obtain: if
cat /work/test/titi
is issued from the directory c:/work/test
__solve_symlinks gives a correct answer,
while it is no more correct if issued from an other directory
because it gives a relative, not an absolute path.
(and both are correct with cat c:/work/test/titi)

I have then tried to compile the test program with xsymlink.c and debug with dbg
I found that the comment at line 70 in xsymlink.c

    /* Begin by start pointing at the first character and end pointing
       at the first path separator.  In the cases like "/foo" end will
       point to the next path separator.  In all cases, if there are no
       path separators left, end will point to the end of string.
     */

is not true with fn = /work/test/titi
end and start point both to the first /
(and then to the end of __real_path after the instruction which follows)

To restore the behavior indicated in the comment I apply the following diff

--- xsymlink.c.orig	2003-02-06 20:42:38.000000000 +0000
+++ xsymlink.c	2004-05-05 19:29:40.000000000 +0000
@@ -74,7 +74,9 @@
      */
     start = __real_path;
     end = strpbrk(__real_path, "/\\");
-   if (!end || (start == end))
+   if (start == end)
+      end = strpbrk(__real_path + 1, "/\\");
+   if (!end)
        end = __real_path + strlen(__real_path);
     while (start && *start)
     {


Then I obtain the correct answers

fn = "c:/work/test/titi"
File c:/work/test/titi is really c:/work/test/../toto

fn = "/work/test/titi"
File /work/test/titi is really /work/test/../toto

I have tried some other checks with various fn, but it would be better to run
a complete test suite (like the one in the above mentioned thread) to
be sure I have not introduced some other error elsewhere

Maurice

BTW: is there a simple way to answer directly to mails found in the
mail archive: I have used copy and paste from the archive, but headers
to show that it is an answer to an other mail will not be present


-- 
        Maurice Lombardi
Laboratoire de  Spectrometrie Physique,
Universite Joseph Fourier de Grenoble, BP87
38402 Saint Martin d'Heres Cedex     FRANCE
Tel: 33 (0)4 76 51 47 51
Fax: 33 (0)4 76 63 54 95
mailto:Maurice DOT Lombardi AT ujf-grenoble DOT fr

- Raw text -