0

I'm having an extremely strange problem with ant. This snippet produces a set of files with the correct names and timestamps, but with obsolete contents.

<target name="inflate-workspace">
    <copy todir="${rns.workspace.dir}" preservelastmodified="true" >
        <fileset dir="${git.dir}/azia" />
        <fileset dir="${git.dir}/scrap-menagerie" />
    </copy>
</target>

The resulting timestamps in toDir correctly match those in the filesets, but the contents of each file is about 2 days old. I activated the verbose flag and manually verified that the source and destination directories are correct. I also manually deleted the toDir and ran the target in isolation, to be sure nothing else weird was happening. Running cp -R ... with the exact same directories works perfect.

The environment is Debian on VBox, hosted in Windows 7. Google turns up nothing related to "ant copy obsolete file contents" or anything like it... anyone heard of such a thing? Please let me know, it's really a bother to have ant copy broken!

A.H.
  • 63,967
  • 15
  • 92
  • 126
Byron Hawkins
  • 2,536
  • 2
  • 24
  • 34
  • What is your problem: That files are copied which you think should not be copied? Or that some files are _not_ copied but should have been? – A.H. Nov 05 '11 at 14:31
  • The correct set of files is being copied, but the text inside each file is 2 days obsolete. It happens even if I delete the entire destination directory. All the files show up, but I can open each one and see obsolete data inside. Replicating the process with "cp -R" copies the correct files with correct contents. – Byron Hawkins Nov 06 '11 at 13:57
  • I don't get it: If you delete the destination and call ant, where does the old data come from? It must be in the source. – A.H. Nov 06 '11 at 14:27
  • This is why I say it's "extremely strange"... I can't find anyplace where the old data could be coming from. Perhaps there is some kind of a bug in VBox shared folders, though that doesn't explain why "cp -R" works. I really can't find anything understandable about it. – Byron Hawkins Nov 06 '11 at 14:50
  • Can it be, that both directories contain files with the same sub-path? – A.H. Nov 06 '11 at 15:03
  • I'm not quite sure what you mean. The destination is empty at the beginning of the ant task, so it hasn't got any sub-paths at that point. The obsolete data is nowhere to be found on disk--it was overwritten days ago. Are there other paths that could be involved here? – Byron Hawkins Nov 06 '11 at 15:34
  • I wanted to know whether for example both `azia/foo/bar/bla.txt` _and_ `scrap-menagerie/foo/bar/bla.txt` exists. Both would end up in the same file and it would be kind of random which one wins. – A.H. Nov 06 '11 at 15:39
  • Ah, I see. Sadly no, they are distinct. The project trees actually start within each top-level folder, and each project root has a fully unique name. After restarting the box it is now copying correct contents, so it seems to be filesystem weirdness of some kind. It makes me wonder what happens when a directory is deleted and then re-created (empty) in the same exact place on the physical disk--can the contents accidentally be "resuscitated" by the `mkdir`? Seems like `mkdir` is so old it could never have that kind of bug, but maybe on a VBox share it could. – Byron Hawkins Nov 06 '11 at 22:26

3 Answers3

0

Check for .class files that could be left forgotten and delete them before building next time with ant.

Jerzy Kiler
  • 2,795
  • 4
  • 18
  • 12
0

Try adding overwrite="true" to your copy command.

  • Well, it happens even if I delete the entire destination directory. Perhaps there is some strange bug in VBox shared folders, though it always works correctly using "cp -R". – Byron Hawkins Nov 06 '11 at 13:58
0

The problem here is that ant 1.8.0 was simply broken. I can't imagine why it was ever posted, or why it's still in synaptic for Debian. What a horrible bug... hacky apache.

Byron Hawkins
  • 2,536
  • 2
  • 24
  • 34
  • Do you suggest ant 1.8.0 is able to cache contents of your files for 2 days? Your problem lies somewhere else. If you deleted the `toDir` folder it was not a complete isolation. More complete isolation would be to use a different destination folder, which never existed. – Jarekczek Feb 29 '12 at 08:58
  • I don't think ant is "caching" anything. There are numerous possibilities, for example, ant could use a temp area for staging directory copies. It would be very simple for a bug in related code to yield stale file data on directory copy. I could investigate the code changes and see what the problem was, but I'm just happy it works in the latest version. – Byron Hawkins Mar 01 '12 at 12:48