I looked, but didn't find any discussion on the new granularity FileUtils.getFileTimestampGranularity. This is messing up my builds big-time.
If you are on Windows and you run two COPY operations within two seconds of each other, the second COPY will be skipped.
<project default="x"> <target name="x"> <touch file="aaa"/> <copy file="aaa" tofile="bbb"/> <sleep seconds="1"/> <touch file="aaa"/> <copy file="aaa" tofile="bbb"/> </target> </project>
G:\temp>ant -verbose Apache Ant version 1.6.2 compiled on July 16 2004 Buildfile: build.xml Detected Java version: 1.4 in: C:\util\jdk\1.4.2\jre Detected OS: Windows 2003 parsing buildfile G:\temp\build.xml with URI = file:///G:/temp/build.xml Project base dir set to: G:\temp [property] Loading Environment env. Build sequence for target `x' is [x] Complete build sequence is [x, ]
x: [copy] Copying 1 file to G:\temp [copy] Copying G:\temp\aaa to G:\temp\bbb [sleep] sleeping for 1000 milliseconds [copy] G:\temp\aaa omitted as G:\temp\bbb is up to date.
BUILD SUCCESSFUL Total time: 3 seconds G:\temp>
The problem stems from this code in FileUtils.java.
public long getFileTimestampGranularity() { if (Os.isFamily("dos")) { return FAT_FILE_TIMESTAMP_GRANULARITY; } else { return 0; } }
it currently looks like this on Ant1.7; we can get granularity problems on Unix too if we try hard enough.
public long getFileTimestampGranularity() {
return onDos
? FAT_FILE_TIMESTAMP_GRANULARITY : UNIX_FILE_TIMESTAMP_GRANULARITY;
}
This is a very poor test. I guess there's a limitted granularity of timestamps on FAT formatted disks. But this test is assuming that any drive under DOS or Windows is FAT formatted.
In the absence of any easy side-effect-free way to determine whether a filesys is FAT, we have to. Also note that there is more to life than NTFS, there is
-remote mounted drives, SMB, Netware, NFS
-Clearcase virtual drives
-USB filesystems
-floppies
-CDFS (not really writeable on Windows)
My build files have this pattern:
<make a temporary copy of file-A> <work on temporary copy, growing and changing it> <when work is complete, replace master copy with temporary>
If the work takes more than two seconds (or build is run on other os, unix for example), then the ANT COPY works. If the work completes in under two seconds on Windows, ANT COPY fails.
so really, your code has always been dependent upon timing. If you want a forced copy, dont use timestamp information *at all*
Temporary work-around is to override the granularity attribute on COPY. But the root cause of the problem (bad test in FileUtils) needs to be fixed.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33906
Marked as wontfix. you can override the granularity, that is what it is there for.
I'm sorry you've wasted time with a problem, I regret that moving up to a recent Ant build has broken your code. But the filesystem granularity was creating other problems. There is no right answer here.
-steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
