Thanks for your consideration. I think you are testing the wrong thing
-- an OS test is not a substitute for FS test. This whole thing has a
"bad smell" to it because the granularity is worming its way into Unix
special cases, per your note, and ANT users now need to compensate for
the cases at the build-file level (with flags such as override,
granularity, for each and every COPY; and I think this also appears in
other tasks such as ZIP). I wish that an alternative approach had been
taken to granularity (e.g. explicit granularity file-system override
pragmas at the beginning of the build-file, or some such). I see the
need for granularity, but, with all due respect, I disagree with how it
was implemented. The change broke my builds and has introduced extra
complexity and a lack of confidence in ANTs disk-based operations.
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
> Xxx Yyy wrote:
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
