ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: New COPY granularity breaks builds on Windows 2000
Date Tue, 08 Mar 2005 23:43:07 GMT
Steve Loughran wrote:

>
> 1. we could have a property "ant.filesys.granularity" which can be set 
> to something in a build.properties or on the command line. if unset, 
> you get the default..

I don't have a problem with this, but I know the general reaction is "No 
Magic Properties".

>
> 2. we could have a task to query the current granularity.

I'm not a fan. What if the build file (that you can't change) doesn't do 
this? I don't see what it buys you over specifying granularity. 
Portability, I guess, but at the cost of an extra task required for 
every build file that wanted to be portable.

>
> 3. In theory we can test a DOS filesys for being NTFS, or at least not FAT

I'm hung up on the "when" of this. Does every Ant startup have to create 
three files one second apart? Or do we do this check the first time we 
access any file system? If so, how do we know when we've changed 
filesystems?

Perhaps what we need to do is improve the heuristics. Change 
FileUtils.java to something like:

    private static boolean onDos = Os.isFamily("dos");
    private static boolean onWin9x = Os.isFamily("win9x");
    private static boolean onWindows = Os.isFamily("windows");
    public long getFileTimestampGranularity() {
        return onWin9x ? FAT_FILE_TIMESTAMP_GRANULARITY :
            (onWindows ? 0 :   // NTFS has a 100 nanosecond granularity
            (onDos ? FAT_FILE_TIMESTAMP_GRANULARITY :
            UNIX_FILE_TIMESTAMP_GRANULARITY));

Not perfect, but getting better. Perhaps in combination with number 1.

>   Or we assume that drives A: and B: are FAT,

And how do we know if we are on A: or B:? They could be the current drives.

>
> The other thing is that once we have an override point, that applies 
> everywhere, we could go
> -win9x : 2s
> -WinNT systems: 1s *unless overriden*. That is, we say "we assume NTFS 
> unless you say otherwise, either in the global properties or   in a 
> <copy> task.

Yes, that is why I like including option 1 in combination with improved 
heuristics. You could use the override for the selectors that require 
knowledge of granularity as well.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message