Xxx Yyy wrote:
That is true, but there is no FS test. This code is not trying to be an FS test, it is trying to be smart about guessing a default value using whatever information is available. It is a heuristic.Thanks for your consideration. I think you are testing the wrong thing -- an OS test is not a substitute for FS test.
Now, is this the right guess to make? Are we correct more than 50% of the time? Nowadays, probably not. But more importantly, do we "do no harm" more frequently with this default? I'd guess probably so, since it is unusual to do copies from and to the same file within two seconds.
So absent some file system test you can point us to, someone is going to bear the burden of specifying granularity. By going with the default we have, I think that burden is borne by the fewest number of people. It is just unfortunate that in this instance, you are among that fewest number.
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 was thinking about this.
the original example may have been inherently brittle to change - a sufficiently fast transform could have taken 0 seconds, but the fact is, our granularity logic has broken the build on windows, but possibly not Unix.
We can't say 'set the granularity value' because that relies on the person with the problem being capable of editing the build file. What if it came from somebody else, somebody who works on a unix box? We need a way of making a build file work on a windows/NTFS system without requiring edits to the build, else we break transparency of platform.
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..
2. we could have a task to query the current granularity.
3. In theory we can test a DOS filesys for being NTFS, or at least not FAT
(a) NTFS files are streams, f.txt:0 is the default stream, but you can add more like f.txt:1 that may work from Java.
(b) Maybe there is some case or file length logic we can try too
(c) We could create 3 files, all at t, t+1, t+2, then read the timestamps. If they are all 1s apart, then we are on a proper FS. If two have the same timestamp, it is FAT. I like this test, as it would work over the net, etc, etc, and because it test the behaviour I want -granularity.
given we can do the tests, when and how? We could hit the temp dir, do the files and assume that is the system granularity unless overridden by end users. Or we assume that drives A: and B: are FAT,
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.
-Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
