On Tue, 04 Sep 2001, Alejandro Abdelnur <[EMAIL PROTECTED]> wrote: > i've run into a similar problem in the ant's antfile, the problem > appears to be a bug in the java.io.File.isAbsolute() method in the > windows platform.
Judging from your patch I assume that you think File.isAbsolute() should return true for \temp on Windows, right? >From the javadocs of File: >> An absolute pathname is complete in that no other information is >> required in order to locate the file that it denotes. with this definition, I think you are wrong. A completely different issue is whether FileUtils.normalize() should treat \temp the same way it treats an absolute path (it does) - I'm not sure as I cannot really see all consequences here. In which situation would a Windows user (I'm not part of that community, so I don't really know) use \temp instead of C:\temp? > i think the place to add this workaround is the > FileUtils.normalize() method, I think it already treats paths starting with File.separator as absolute paths. Looks as if <ant> should use FileUtils.resolveFile(dir, antfile) in its execute method. > then the ant.setAntfile() method should be retrofitted to use the > normalized (similarly any other attribute that expects a file name). Most tasks have setters that expect a File argument when they expect filenames - these setters will receive File instances that went through FileUtils.normalize (via FileUtils.resolveFile) automatically. Stefan
