Re: OpenVMS changes (was Re: FileUtils#normalize(File))

2003-08-01 Thread Stefan Bodewig
On Thu, 31 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote: >> > I was thinking about the FileUtils#getSetLastModified(), which >> > using reflection returns the File#setLastModified(long) method. >> > Alas, I found that exactly this method doesn't have any effect on >> > OpenVMS >> >> Well at

RE: OpenVMS changes (was Re: FileUtils#normalize(File))

2003-07-31 Thread Wannheden, Knut
Stefan, > > On the downside a FileUtils#toVMSPath(File) would push the OS > > awareness responsibility up a level, in which case > > Commandline.Argument.setFile(File) would have to check for OpenVMS > > and call this method. > > I agree, Commandline.Argument shouldn't need to be aware of this. >

OpenVMS changes (was Re: FileUtils#normalize(File))

2003-07-31 Thread Stefan Bodewig
On Wed, 30 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote: > On the downside a FileUtils#toVMSPath(File) would push the OS > awareness responsibility up a level, in which case > Commandline.Argument.setFile(File) would have to check for OpenVMS > and call this method. I agree, Commandline.Arg

RE: FileUtils#normalize(File)

2003-07-30 Thread Wannheden, Knut
> > For VMS I intend to add a method FileUtils#toVMSPath(File):String. > > I was just thinking if a more generic > > FileUtils#toOSPath(File):String would make sense. What do you > > think? > > There currently is no need for it except in the OpenVMS case, we could > add toOSPAth later IMHO. > O

RE: FileUtils#normalize(File)

2003-07-30 Thread Wannheden, Knut
Stefan, > > 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. > > I'm not entirely sure (we extracted the code from Project way back > IIRC). On problem I can imagine is that of

Re: FileUtils#normalize(File)

2003-07-29 Thread Stefan Bodewig
On Tue, 29 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote: > For VMS I intend to add a method FileUtils#toVMSPath(File):String. > I was just thinking if a more generic > FileUtils#toOSPath(File):String would make sense. What do you > think? There currently is no need for it except in the Ope

Re: FileUtils#normalize(File)

2003-07-29 Thread Stefan Bodewig
On Mon, 28 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote: > 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. I'm not entirely sure (we extracted the code from Project way back I

RE: FileUtils#normalize(File)

2003-07-29 Thread Wannheden, Knut
> > > I get the impression FileUtils#normalize(File) mimics the behaviour > > of File#getCanonicalFile(). > > To a certain extent, yes. > > > But I suppose there's a good reason for not using that method > > Symbolic links. > Makes sense. I've added that as a comment to FileUtils#normalize(S

Re: FileUtils#normalize(File)

2003-07-29 Thread Stefan Bodewig
On Mon, 28 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote: > I get the impression FileUtils#normalize(File) mimics the behaviour > of File#getCanonicalFile(). To a certain extent, yes. > But I suppose there's a good reason for not using that method Symbolic links. On Unix, getCanonicalPath

RE: FileUtils#normalize(File)

2003-07-28 Thread Wannheden, Knut
> > > 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 i

Re: FileUtils#normalize(File)

2003-07-28 Thread Antoine Levy-Lambert
- Original Message - From: "Wannheden, Knut" <[EMAIL PROTECTED]> Sent: Monday, July 28, 2003 12:33 PM > 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 comp