Mail Archives: djgpp-workers/2003/01/18/07:10:37
Hello.
Laurynas Biveinis wrote:
> Well, maybe I'm on drugs,
Maybe the problem is that I'm not on drugs (caffeine)! ;)
> but I was unable to find good testcases for debugging it. It passes with
> flying colours every single test I made, except for this case:
>
> symlink("c:/autoexec.bat", "/link");
> test_success("/link", "c:/autoexec.bat");
>
> I.e. it didn't resolve /link properly. But I failed to create any more
> failing tests, including situations described by you. Maybe you could
> give me the testcase a patch to tests/libc/compat/unistd/xsymlink.c or
> precisely describe particular directory and file layout for uncovering
> the bugs?
I reverted my changes and I'm now running fileutils, sh-utils and textutils
built with DJGPP CVS HEAD. But the test program still fails for me:
bash-2.04$ pwd
c:/djgpp.204/tests/libc/compat/unistd
bash-2.04$ ./xsymlink.exe
Running __solve_symlinks() and readlink() testsuite:
Tests that check __solve_symlinks() works:
Test 1 passed
Test 2 passed
Test 3 passed
Test 4 passed
Test 5 passed
Test 6 passed
Test 7 passed
Test 8 passed
Test 9 passed
Test 10 passed
Test 11 passed
Test 12 passed
Test 13 passed
Tests that check __solve_symlinks() based on current directory:
Test 1: Solving
c:/djgpp.204/tests/libc/compat/unistd/../../../../../djgpp.204/t
ests/libc/compat/unistd/test1
Test 1 passed
Test 2: Solving c:../../../../../djgpp.204/tests/libc/compat/unistd/test1
Test 2 passed
Test 3: Solving c:../../../../../../djgpp.204/tests/libc/compat/unistd/test1
Test 3 failed - __solve_symlinks returns wrong resolved path
Returned path: c:/djgpp.204/tests/libc/compat/unistd/test1
Expected path: c:/djgpp.204/tests/libc/compat/unistd/file1
Tests that check __solve_symlinks() failure cases:
Test 1 passed
Test 2 passed
FAIL
Do you expect this test to fail?
Here some ideas for more tests:
* symlinks between drives;
* paths using /dev/<drive> instead of <drive>:;
* paths using environment variables in paths - e.g.: /dev/env/FOO.
Basically tests that mix absolute and relative paths in every possible way.
Most of the tests are too "normal" at the moment IMHO. Not that I am
criticising. It's just that you may not have thought of bizarre filenames as
much as I have, while testing fileutils, etc. ;)
> Below are the new testcases from testsuite I've used, and the patch I'm
> commiting in a second to fix /link case. The fix is trivial.
>
> symlink("c:/autoexec.bat", "/link");
> test_success("c:/link", "c:/autoexec.bat");
> test_success("/link", "c:/autoexec.bat");
> test_success("c://link", "c:/autoexec.bat");
> test_success("//link", "c:/autoexec.bat");
> test_success("c:/./link", "c:/autoexec.bat");
> test_success("/../link", "c:/autoexec.bat");
> test_success("c:/../link", "c:/autoexec.bat");
> test_success("/../../link", "c:/autoexec.bat");
> test_success("c:/../../link", "c:/autoexec.bat");
> /* FIXME below, but note that you're insane to run this test
> really that deep :) */
> test_success("c:../../../../../../../../../../../../../../../link",
> "c:/autoexec.bat");
[snip]
Why is this marked as a FIXME?
Why is it insane? Sure, having more than 8 levels of directories is
unsupported on DOS, but the code should cope with excess ".."s.
The patch you posted looked good.
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -