`test -e` fails on (healthy) symlink

[xparq]

$ pwd
C:/sz/prj/Args/test

$ busybox test -e tmp/symlink && echo ok
ok
$ test -e tmp/symlink && echo ok

:-o

$ which busybox
C:/SW/devel/tool/w64devkit/w64devkit-32/bin/busybox.exe
$ which test
test

But wait, there's more:

$ cd tmp && test -e symlink && echo ok
ok

:-oo

$ readlink symlink
C:/sz/prj/Args/test/tmp/README.out
$ test -f README.out && echo ok
ok

Any idea, what can cause this?

[rmyorston]

Any idea, what can cause this?

I thought so, but it doesn't match your report.

There was a bug in the last commit before the FRP-4716 release (which is the version used in w64devkit 1.17.0). It was later fixed. But that related to relative symlinks, an absolute symlink should be OK.

I can reproduce your problem in w64devkit if the symlink is relative but not if it's absolute.

[skeeto]

I'm also unable to reproduce the issue for absolute symlinks. I tested in an isolated "home=." w64devkit.ini config run as administrator (instead of changing the overall system configuration regarding symlinks):

mkdir tmp

echo hello >tmp/README.out

ln -s "$PWD/tmp/README.out" tmp/symlink

test -e tmp/symlink && echo ok

ok

busybox test -e tmp/symlink && echo ok

ok

Unless you've added another one, there should only be one shell, busybox ash, on your path and when you invoke "test" I believe busybox ash prefers its built-in test versus the "test.exe" alias I put in bin/, which agrees with your "which" output. (You could delete or move it as another test.) When you use "busybox test" I believe it's starting another process.

Since it's now possible to build busybox in w64devkit, you could compile a debug build, open it in w64devkit's own GDB, set a breakpoint in the test app, start sh, run your test, then step through "test -e". This was to be my own next step if I could reproduce. I recommend "set new-console" so that the shell runs in its own console window, leaving the original console to GDB. If you want to regain control in GDB without killing the shell process, run w64devkit's "debugbreak" command from anywhere, even the debuggee.

[xparq]

Thank you, guys. At the moment I'm also unable to reproduce it. :-o (With new files, as that previous tmp dir was gone.)

BTW, sh was just the default shell launched by my w64devkit shortcut, via C:\SW\devel\tool\w64devkit\w64devkit-32\w64devkit.exe. (Vanilla Win10/64 here.)

Git's shell is also on the path, FWIW, but it comes later (line-breaks added for easier reading):

$ echo $PATH
C:/SW/devel/tool/w64devkit/w64devkit-32/bin;
C:/Windows/system32;C:/Windows;
C:/Windows/System32/Wbem;
C:/Windows/System32/WindowsPowerShell/v1.0/;
C:/Windows/System32/OpenSSH/;
C:/Program Files (x86)/Bitvise SSH Client;
C:/Program Files/Git/cmd;
C:/Program Files/Git/mingw64/bin;
C:/Program Files/Git/usr/bin;
C:/Program Files (x86)/VSCodium/bin;
C:/Program Files (x86)/GitExtensions/;
C:/Program Files/dotnet/;
C:/Program Files/GitHub CLI/;
<... presumably irrelevant additional entries ...>

[xparq]

I'm closing this "tentatively", as nobody else seems to have had anything similar apparently, and even I don't have it any more... And it feels so bad to have this crosshair on your nice project. :)

[xparq]

Wait, I even found a typo in the original report, which I have now fixed, retrospectively... I have no idea now if that could have been the actual cause of the anomaly, as originally I noticed the problem in a different context (a script misbehaving), where there was no such typo.