1.3.22: executing relative symlinks on network shares
Daniel Villeneuve
danielv@ad-opt.com
Wed Jul 30 15:22:00 GMT 2003
Hi,
I have a problem when trying to execute relative symlinks
located on network shares: when I create such a symlink,
Cygwin does not find the pointed-to executable and continues
down the PATH. Bash does not have the problem because I
think it does not rely on find_exec to find executables, but
scans the PATH itself. Perl and the smaller C program
given hereafter use execvp (which calls find_exec) and fail.
cat >callgcc.c <<EOF
#include <unistd.h>
#include <stdlib.h>
int main(void)
{
char *argv[] = { "gcc", "--version", NULL };
execvp("gcc", argv);
perror("callgcc");
exit(EXIT_FAILURE);
}
EOF
To illustrate the problem, I need to have access to a
network share directly mounted (via mount) using the
Windows share name (//machine/account).
Here is a complete setup. My $HOME is not on the same
network share than the one I'm using for the example.
mount -buf '//machine/account' /home/account
cd /home/account
mkdir t
cd t
ln -s /usr/bin/gcc-2.exe foo.exe
ln -s ../t/foo.exe gcc.exe
cd $HOME
gcc -o callgcc callgcc.c # the small program above
PATH=/home/account/t:$PATH ./callgcc
=> gcc 3.2 !
The relevant output of strace is in attachment here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fe-without-netuse
Type: application/octet-stream
Size: 4817 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030730/53c9f337/attachment.obj>
-------------- next part --------------
The output should be gcc 2.95.3-10, since the gcc.exe in
/home/account/t points to foo.exe which points to
/usr/bin/gcc-2.exe.
If I do the following:
net use r: '\\machine\account'
umount -u /home/account
mount -buf r: /home/account
the behavior is correct.
The relevant output of strace is in attachment here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fe-with-netuse
Type: application/octet-stream
Size: 3674 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030730/53c9f337/attachment-0001.obj>
-------------- next part --------------
The problem seems to be around symlink_info::check,
performing an unwanted side effect on the analyzed path in
one case but not the other.
The output of "cygcheck -s" is in attachment here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check
Type: application/octet-stream
Size: 9597 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030730/53c9f337/attachment-0002.obj>
-------------- next part --------------
Let me know if more information is needed.
Thanks for your time,
--
Daniel Villeneuve
AD OPT Technologies Inc.
-------------- next part --------------
--
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/
More information about the Cygwin
mailing list