Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: djgpp-workers AT delorie DOT com
From: Nate Eldredge <nate AT cartsys DOT com>
Subject: Links to links
Date: Fri, 29 May 1998 16:54:05 -0700
Message-ID: <19980529235344.AAF16281@ppp116.cartsys.com>
Precedence: bulk

A shortcoming of the current symlink implementation is that links to links
do not work. E.g:

c:\temp> cat >hello.c
#include <stdio.h>
int main() { printf("Hello, world\n"); return 0; }
^Z

c:\temp> gcc -o hello.exe hello.c

c:\temp> hello
Hello, world

c:\temp> ln -s hello.exe hello2.exe

c:\temp> hello2
Hello, world

c:\temp> ln -s hello2.exe hello3.exe

c:\temp> hello3
C:\TEMP\hello2.EXE: not COFF (Check for viruses)

This slightly alarming message is caused by the fact that the stub tries to
load the COFF directly from the `loadname' file. IMHO, something should be
done about this. I see several options:

1. Make the stub exec `loadname', instead of loading directly from it. I
realize everybody's reluctant to mess with the stub, and this would also be
problematic as far as getting argv[0] right.
2. Make `symlink' fail if it tries to create a link to a link. How that
would be possible, I don't know. Either it would have to look into the stub
and check that `loadname' was the same as the file name, or see that the
file length was greater than 2K. Either one would cause some bloat.
3. Change the message to something less confusing to a newbie, and have the
parent's `spawn' be informed and set `errno' to EMLINK. Problems: Tricky to
separate that problem from some other loading error, especially in the
confines of the stub, and there's no good way to pass the error back to the
parent.
4. Document it. There may be problems; perhaps some Unix makefiles expect
links to links to work.

Isn't there a #define somewhere that says how many symlinks the system will
follow? There's a limit on Unix systems, usually to prevent infinite loops.
We should set it to 1.

Any other ideas?

Nate Eldredge
nate AT cartsys DOT com