Bug 10755

[Stefan Bodewig <bo...@apache.org>]

OK,

for the test cases that are there, this bug is fixed.  But I'm rather
sure that the tests are not good enough 8-)

I think it will fail for <zipfileset>s with <excludes> (will update
even when it shouldn't) and probably in some cases for <excludes> on
the "implicit" fileset - I'll try to come up with testcases for this,
to back the claims.

Beyond what Antoine and myself had been talking about I had to put in
an additional change without which the <jar> tests would fail
randomly:

ZIP archives store file modification times with a granularity of two
seconds.  Our ZipOutputStream used to round this down to the next
lower even number.  This in turn means that many times the zip entry
for a file is older than the file itselt, leading to the old "always
updates" behavior for these cases.

I've now changed the code to round up to the next higher even number,
this in turn means that we will miss some updates in border cases, but
I had to make a choice.

One thing that has to be addressed for bc is that Zip#isUpToDate has
changed its signature.  I think this can be solved by adding

    // old signature
    protected boolean isUpToDate(FileScanner[] scanners, File zipFile)
        throws BuildException {
        return true;
    }

and at the top of the new isUpToDate() method add

    protected boolean isUpToDate(ResourceScanner[] scanners, 
                                 FileSet[] fss, File zipFile)
        throws BuildException {

        if (!isUpToDate(scanners, zipFile)) {
            return false;
        }

This would allow existing subclasses to have their isUpToDate method
called, but they'd no longer be able to suppress the check in Zip
completely.  This certainly warrants a warning in WHATSNEW.

Anyone with a better idea?

Then there are a couple of nits like "Should Resource#isExists better
be Resource#exists?".  I'll leave it to this list to review and refine
what we have.  Once we are happy, I volunteer to merge the changes
into the 1.5 branch.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Bug 10755

[Stefan Bodewig <bo...@apache.org>]

one more thing I discovered:

In update mode it has always been possible that we replace a given
ZipEntry with an older version as we add all "included files" from the
filesets, without checking whether they are really newer (the test is
only used to determine whether the archive should be updated or not).

With the old code, this scenario is pretty unlikely as that would
imply ZipEntrys of the archive to update having a newer date than the
date of the archive itself, but with the new code, this is likely to
happen.

I'll try to fix this (again, trying to find time to write the tests
first), but it will mean we need even more reshuffling in Zip to make
it work at a reasonable speed.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>