https://issues.apache.org/bugzilla/show_bug.cgi?id=57086
Bug ID: 57086
Summary: COPY task sees source files up to date until they are
at least one minute out of date.
Product: Ant
Version: 1.9.2
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
Assignee: [email protected]
Reporter: [email protected]
I have source files on an Intel RAID-1 under Windows 7 x64, and target files
located on an SMB share.
When I change a source file (say a .css file) and run a the copy-changed-files
ant target:
<target name="copy-changed-files" description="Copy files to instance"
depends="x-check-webapp">
<copy todir="${remote.appdir}/css" verbose="true">
<fileset dir="css/" casesensitive="yes">
<include name="*.css"/>
<include name="web/**"/>
</fileset>
</copy>
...
</target>
then just that one modified file gets copied over as expected. However, if I
then change the file again, and run the copy-changed-files target again, the
file does NOT get copied over. It seems that ANT does not recognize the file
has changed. If I wait for one to two minutes before saving the modified file
again (I have not timed the precision, but I do know it's always at LEAST one
minute) then ANT copies the file as expected.
If I open the project on a Mac running Mavericks or Yosemite (different source
(git working-) directory, of course, but EXACTLY the same SMB share), this
problem never occurs. Every time I save the file, and run the
copy-changed-files ANT target, the file gets copied over. If it doesn't change,
then it doesn't get copied.
Often, it is more than one minute (or so) between file saves. But occasionally
I will make a "one-liner" and attempt to copy the file for testing.
Unfortunately, I have to wait. It's maddening.
I've tried disabling caching on the RAID array, but that didn't help. I've
tried all reasonable values for granularity from 0 to 1000000, but that didn't
help, although higher settings made it worse. I tried moving from Eclipse
Kepler (ant 1.8.4) to Eclipse Luna (ant 1.9.2), but that didn't help. Searching
the Internet for this issue returned no matching results.
When I save the file, and immediately check it's modified timestamp in Windows
7 Explorer, it has the correct time down to the second, and the SMB share also
shows timestamps with one-second resolution. So both file systems have the
requisite file modification resolution.
I'm at a loss, here.
--
You are receiving this mail because:
You are the assignee for the bug.
