daniel.daugherty@Eng 1999-08-19

I encountered this bug while writing test cases for the following bug:

    4197204 4/5 File URL with UNC path does not work

I had a typo in one of the test cases and accidently used the same file
name as the previous test case. I was surprised to observe that
sometimes the data read from the file URL in the second test case was
the data written in the first test case and *not* the data written by
the second test case.

I have distilled my original test program down to the salient parts and
consequently the problem is much more reproducible. Here is a sample
from the fail.log file:

    java TestURLRead1 -l 50
    ERROR: "\\owjones\local\test_file_4197204": data read is not correct.
    ERROR: expected="SpecFile_4197204_case2" actual="SpecFile_4197204_case1"
    :
    :
    ERROR: "\\owjones\local\test_file_4197204": data read is not correct.
    ERROR: expected="SpecFile_4197204_case2" actual="SpecFile_4197204_case1"
    FINALSTATUS:TestURLRead:EXIT_FAIL:1:Number of FAILURES:46:TEST FAILED

First case:

    The data "SpecFile_4197204_case1" was written to a file using the
    UNC pathname: "\\owjones\local\test_file_4197204". The data was
    read from the file via the URL: "file:L:\\test_file_4197204".

Second case:

    The data "SpecFile_4197204_case2" was written to a file using the
    UNC pathname: "\\owjones\local\test_file_4197204". The data was
    read from the file via the URL: "file:L:/test_file_4197204".

In the second case, the read often returns "SpecFile_4197204_case1"
instead of "SpecFile_4197204_case2". Using a 400MHZ Pentium II running
WinNT 4.0, there were typically 46-50 failures. Using a 450MHZ Pentium
III running Win98, there were typically 50 failures.

owjones is an Ultra 30 running Solaris 2.6 and it exports the /local
file system to the Win* machines. I am using Solstice NFS Client 3.2 on
the Win* machines.

I have attached the following files:

    fail.log - failure log from WinNT machine
    TestURLRead1.class - test writes via UNC and reads from absolute
file URL
    TestURLRead1.java - source for previous test
    TestURLRead2.class - test writes via relative path and reads from
                          relative file URL
    TestURLRead2.java - source for previous test
    TestURLRead3.class - test writes via absolute path and reads from
absolute file URL
    TestURLRead3.java - source for previous test

    ParseOptions.class - command option parsing helper class
    ParseTestOptions.class - test app option parsing helper class
    TestDriver.class - test driver helper class
    TestDriverConstants.class - test driver constants helper class

The TestURLRead2 application shows that writing via a relative pathname
and reading from a relative file URL is okay.

The TestURLRead3 application shows that writing via an absolute pathname
and reading from an absolute file URL is okay (the same URL used by
TestURLRead1).

The problem only appears to be in data written via a UNC pathname.
Since the other two test programs work, I'm inclined to believe that
Solstice NFS Client is not the culprit and there is something up with
the UNC support in java.

I have reproduced this bug using JDK-Kestrel Build O.

daniel.daugherty@Eng 1999-08-20

After discussing this bug with Jeff Nisewanger, I have reproduced this
bug without using a URL to read the file. I have attached two new files:

    TestUNCWrite1.class - test writes via UNC and reads from absolute path
    TestUNCWrite1.java - source for the previous test