Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E82D7EC.AD18E107@phekda.freeserve.co.uk>
Date: Thu, 27 Mar 2003 10:52:28 +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 <djgpp-workers AT delorie DOT com>
Subject: Bug in DJGPP 2.03's symlink
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

There seems to be a bug in DJGPP 2.03's symlink.

Case 1:

rm -f foo bar bar.exe
touch foo
symlink("foo", "bar");

This will create a program bar.exe.

Case 2:

rm -f foo bar bar.exe
echo wibblewibble > foo
symlink("foo", "bar");

symlink() will fail with EXDEV.

Why the different behaviour? In both cases foo is not executable.

Files shorter than the header length read in by _check_v2_prog have an invalid
program type. (See src/libc/dos/process/chkv2prog.c.) The problem above arises
because is_v2_prog in src/libc/posix/unistd/symlink.c assumes that an invalid
program type is the same as the file not existing. This is not true. symlink
needs to check whether the file exists.

This behaviour is inconsistent. It makes using "ln -s" on non-executable files
a lottery.

I could fix "ln -s" by shipping a fixed symlink.c with Fileutils 4.1. I
already ship a fixed opendir.c with it.

Bye, Rich =]

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