> > > I've noticed that the normalize(File) method in FileUtils > requires that > the > > File to normalize is absolute. I was wondering what the > reason is for > this > > reason. Would it be too complex to normalize a relative > path on Windows > > systems? > > > I do not know.
I get the impression FileUtils#normalize(File) mimics the behaviour of File#getCanonicalFile(). But I suppose there's a good reason for not using that method (the reason is not that it requires JDK1.2+). Can someone enlighten me? > > I think it makes perfectly sense to normalize a path like > "./foo" into > "foo" > > or "foo/bar/.." into "foo". Even a path like "../foo" > could be normalized > > using the system property "user.dir", but it could also > cause an Exception > > to be thrown as the absolute path "/../foo" would (a Unix > system would > even > > normalize that as "/foo"). > > > > The reason I'm askin is because I wanted to reuse the code > in normalize > > which handles ".." and "." path segments. But maybe I > should copy and > paste > > instead. > The best and most sure option is to factor out the lines of > codes that you > are interested in in a separate method, which would be called both by > Normalize and by your specific code for VMS. > Thanks. With a refactoring possibly both normalize(File) and resolveFile(File, String) could use this method. The reason I'm asking about this method is, as you guessed, that I want to use this in some VMS specific code. The code shall be used to convert a Unix style path (which is both Ant's and Java's default representation) into a VMS path. Originally I thought I'd do this by maintaining all the "." and ".." path segments, but naturally it's easier to only deal with normalized paths. This shouldn't make any difference if this conversion is only applied as a last step by tasks like <exec> and <apply>. Any opinions on this? -- knut
