These are good ideas, but I think you're solving the problem in the
wrong place. In the example Bruce posted, the problem was in the ZIP
"file-system" rather than FAT. A single-property solution wouldn't
help there -- it would solve the 2sec granularity for ZIP at the
expense of reduced granularity resolution everywhere else, that's just
shifting the problem not fixing it. The root cause of the problem
comes from the differing granularities and handling the conflicts and
overlap. Perhaps the touch task, instead of copy, could be modified to
support round-up/down granularities. Then files could be copied to
temporary directories, touched to normalize granularities, and then
compared against zip contents (or other file systems).
Perhaps the extra touch step feels like a "burden". But I would rather
see if explicitly in the build-file rather than hidden. The zip
resolution is a very real problem and should be understood by zip
content developers, not glossed over by ant.
Bruce, thank you for the example. But I think this is a case against
varying defaults. Varying the default based on os adds inconsistencies
to the mix here. Do you have another example with traditional file
systems (e.g. due to FAT and NTFS interactions).
Please note also that FAT is used in other operating-systems, in
growing numbers. Linux can mount, read and write it, and even be
installed on top of FAT. CompactFlash cards which can be read on a
wide variety of os's are FAT{12,16,32}.
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 08 Mar 2005, Bruce Atherton <[EMAIL PROTECTED]> wrote:
> > 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".
>
> Looks like the best option together with improved heuristics for
> Windows (if NTFS really is the more likely choice on WinNT).
>
> >> 2. we could have a task to query the current granularity.
>
> That would have to check every directory involved in the build since
> granularity may be different. That's really a point where we need
> explicit user interaction.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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]
