Interesting. Thanks for mentioning this, Byron.
I think this is a flaw in the test itself. The test
1. creates a directory,
2. captures its lastModified time,
3. adds a file to the directory,
4. adds the directory (and therefore its contents) to the payload,
5. extracts the payload into another place (which should restore the
directory's lastModified to its original value),
6. compares the extracted directory's lastModified value to the
original directory's.
The problem is, I think, that steps 2 and 3 need to be reversed.
Given the resolution of clocks on most systems, it looks as if the
file in the directory is usually created before the clock advances, so
the captured directory lastModified is the same as the actual
lastModified of the original directory after the file is added within
it. But it looks like you are getting the clock to tick between steps
2 and 3 sometimes, which causes the test to fail.
I'll check in a change to the test. Please let me know if that seems
to cure the intermittent failures.
- Tim
On Apr 26, 2010, at 2:19 PM, Byron Nevins wrote:
> Directory lastModified mismatch after extraction 1272138325395,
> 1272138356159
>
>
> line 824 org.glassfish.admin.payload.PayloadFilesManagerTest
>
> Here is the code from the unit test:
>
> System.out.println("Directory lastModified
> mismatch after extraction " +
> dirCreationTime + ", " +
> extractedLastModified);
>
> It looks like the numbers are in nsec which would mean a time stamp
> discrepancy of less than one microsecond.
>
> ***** I've only seen it on Windows 7 and it is intermittent
> ************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>