FAQ
https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

             Bug ID: 59562
            Summary: Regexp mapper + Zip task on Windows
            Product: Ant
            Version: 1.9.7
           Hardware: PC
             Status: NEW
           Severity: normal
           Priority: P2
          Component: Core tasks
           Assignee: notifications@ant.apache.org
           Reporter: g.querret@riverside-software.fr

Using this test case, I see a different behavior on Windows and Linux ; I'm
creating two files, then generating a ZIP file (with regexpmapper to rename
files), wait a few seconds (just in case there's FS timestamp problem) and
re-execute the same Zip task.
On Linux, the second Zip task doesn't do anything (as expected) as the
files are not modified.
On Windows, the Zip file is always updated. With -v, I'm getting :
       [zip] us/xx/xxtest.r added as us/xx/xxtest.r is outdated.
       [zip] us/zz/zztest.r added as us/zz/zztest.r is outdated.
Using Ant 1.9.7, JDK 1.8 on both systems.

Am I doing something wrong, or is there a bug ?

<?xml version="1.0" encoding="utf-8"?>
<project name="test">
  <mkdir dir="src" />
  <touch file="src/xxtest.r" />
  <touch file="src/zztest.r" />
  <zip destFile="foo.zip">
    <mappedresources>
     <fileset dir="src" includes="*.r" />
     <regexpmapper from="^(([a-z][a-z]).*)\.r" to="us/\2/\1.r" />
    </mappedresources>
  </zip>
  <sleep seconds="5" />
  <zip destFile="foo.zip">
    <mappedresources>
     <fileset dir="src" includes="*.r" />
     <regexpmapper from="^(([a-z][a-z]).*)\.r" to="us/\2/\1.r" />
    </mappedresources>
  </zip>
</project>

--
You are receiving this mail because:
You are the assignee for the bug.

Search Discussions

  • Bugzilla at May 17, 2016 at 2:45 pm
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    --- Comment #1 from Gilles QUERRET <g.querret@riverside-software.fr> ---
    Created attachment 33846
       --> https://bz.apache.org/bugzilla/attachment.cgi?id=33846&action=edit
    JUnit test case

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 17, 2016 at 2:45 pm
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    --- Comment #2 from Gilles QUERRET <g.querret@riverside-software.fr> ---
    Created attachment 33847
       --> https://bz.apache.org/bugzilla/attachment.cgi?id=33847&action=edit
    JUnit test case (xml file)

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 17, 2016 at 2:46 pm
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    Gilles QUERRET <g.querret@riverside-software.fr> changed:

                What |Removed |Added
    ----------------------------------------------------------------------------
                      CC| |g.querret@riverside-softwar
    e.fr
                      OS| |All

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 17, 2016 at 8:25 pm
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    --- Comment #3 from Gilles QUERRET <g.querret@riverside-software.fr> ---
    I think I've found the issue, but would like to get confirmation : the
    granularity of file timestamps is different on NTFS and Linux filesystems (1
    and 2000 respectively), however it seems that file entries in ZIP files have a
    different granularity. From my tests, I'm always gettings timestamps from ZIP
    file which are 1.5 seconds more recent than file timestamps, so the ZIP file is
    not updated on Unix (less than 2 seconds), but not on Windows (only 1ms
    granularity).
    Does anybody have enough knowledge of ZIP files to confirm that ?
    A fix could be to have a different granularity based on the resource type we're
    trying to update, but I don't know how easy it would be to do that.

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 18, 2016 at 3:59 am
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    --- Comment #4 from Stefan Bodewig <bodewig@apache.org> ---
    Yes, there are different granularities in this scenario. First of all, ZIPs
    store file times with a granularity of two seconds - and I think this is true
    for FAT and NTFS as well. Most file-system types on Unix use a granularity of
    seconds or even lower than that.

    The default behavior if the zip task is to round the file time up to the next
    even number of seconds in order to avoid the situation you describe - see the
    task's roundup attribute. What you see implies it didn't work correctly.

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 18, 2016 at 6:47 am
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    --- Comment #5 from Gilles QUERRET <g.querret@riverside-software.fr> ---
    I'd say the roundup method is working correctly and as expected. To my mind,
    the problem lies in
    org.apache.tools.ant.types.selectors.SelectorUtils#isOutOfDate(Resource src,
    Resource target, long granularity) method which is called when we determine if
    a file has to be updated. This works correctly for filesystem resources on
    Windows, as the parameter granularity is set to 1 which is the right value on
    NTFS. This granularity is found in
    org.apache.tools.ant.util.FileUtils#getFileTimestampGranularity(). When working
    with ZIP file, this method should return 2000 in order to counterbalance the
    roundup.

    An easy fix (but I don't know the impact yet) would be to replace at line 1545
    of org.apache.tools.ant.taskdefs.Zip the call to
    ResourceUtils.selectOutOfDateSources(this, rs, mapper, getZipScanner()) with
    ResourceUtils.selectOutOfDateSources(this, rs, mapper, getZipScanner(), 2000L)
    so that granularity would be set at the ZIP file level instead of inheriting
    from the OS specific value.

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 18, 2016 at 3:04 pm
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    --- Comment #6 from Gilles QUERRET <g.querret@riverside-software.fr> ---
    Unit tests are OK with this change, including the one I've added to test this
    behavior.
    What does it take to have the change included in the master branch ?

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 19, 2016 at 4:27 am
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    --- Comment #7 from Stefan Bodewig <bodewig@apache.org> ---
    Your idea of a fix looks correct, I'm working on integrating your changes.

    --
    You are receiving this mail because:
    You are the assignee for the bug.
  • Bugzilla at May 19, 2016 at 4:40 am
    https://bz.apache.org/bugzilla/show_bug.cgi?id=59562

    Stefan Bodewig <bodewig@apache.org> changed:

                What |Removed |Added
    ----------------------------------------------------------------------------
                  Status|NEW |RESOLVED
        Target Milestone|--- |1.9.8
              Resolution|--- |FIXED

    --- Comment #8 from Stefan Bodewig <bodewig@apache.org> ---
    Applied your patch and suggestion with commit 0edf3ca - will be fixed in 1.9.8
    and 1.10.0.

    --
    You are receiving this mail because:
    You are the assignee for the bug.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupnotifications @
categoriesant
postedMay 17, '16 at 2:45p
activeMay 19, '16 at 4:40a
posts10
users1
websiteant.apache.org

1 user in discussion

Bugzilla: 10 posts

People

Translate

site design / logo © 2018 Grokbase