DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 39232] - ant.jar has a dependency on ant-launcher.jar in FileUtils.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 39232] New: - ant.jar has a dependency on ant-launcher.jar in FileUtils.

gzilla/show_bug.cgi?id=39232 Summary: ant.jar has a dependency on ant-launcher.jar in FileUtils. Product: Ant Version: 1.6.5 Platform: Other OS/Version: other Status: NEW Severity: normal Priori

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

gzilla/show_bug.cgi?id=35776 --- Additional Comments From [EMAIL PROTECTED] 2005-07-21 20:19 --- (In reply to comment #2) > thx to Matt for the pointer to the existing commons-io FileUtils (see Bug 35818). > Agreed, having symlinks handled by the JVM might be the best solution. But si

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

ONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-07-21 18:04 --- thx to Matt for the pointer to the existing commons-io FileUtils (see Bug 35818). Agreed, having symlinks handled by the JVM might be the best solution. But since we all stumble daily over those and JVMs haven't delive

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

y to get this would be to build cygwin awareness into a JVM, since it is at this level that, e.g. Unix symlinks are handled. > Once this exists, I guess this very useful tool "FileUtils" might find many more > takers and thus could move to jakarta-commons? IIRC there is

DO NOT REPLY [Bug 35776] - amend FileUtils to properly handle cygwin symbolic links

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35776] New: - amend FileUtils to properly handle cygwin symbolic links

gzilla/show_bug.cgi?id=35776 Summary: amend FileUtils to properly handle cygwin symbolic links Product: Ant Version: 1.7Alpha (nightly) Platform: Other OS/Version: other Status: NEW Severity: enhancement Priori

[patch] FileUtils close methods now log to calling tasks log

Based on the feedback, I added in the message retrieved from the io exception. This is just for writer/outputstream. Kev Index: FileUtils.java === RCS file: /home/cvspublic/ant/src/main/org/apache/tools/ant/util/FileUtils.java,v r

Re: sync FileUtils

The close methods are also new. No problem with syncing to ant 1.6.3, just (as mentioned) remove the "deprecated" flags. Peter Matt Benson wrote: There is a lot of stuff in FileUtils that is marked for Ant 1.7 but that is already in use in Tasks that have small changes that would be

Re: sync FileUtils

On Tue, 25 Jan 2005, Steve Loughran <[EMAIL PROTECTED]> wrote: > Matt Benson wrote: >> Does anyone object to my (changing 1.7 to 1.6.3 in >> code) sync the 1.6 branch to HEAD? It will make it >> much easier to sync other changes over from HEAD and >> doesn't appear to carry a lot of risk. > > I'm

Re: sync FileUtils

Matt Benson wrote: --- Steve Loughran <[EMAIL PROTECTED]> wrote: [SNIP] I'm +1 to the changes, except that the non-static stuff should not be marked as deprecated in the 1.6 branch. [SNIP] So we should pre-deprecate them, i.e. "This will be deprecated in a future version."? ;) yeah, something lik

Re: sync FileUtils

--- Steve Loughran <[EMAIL PROTECTED]> wrote: [SNIP] > I'm +1 to the changes, except that the non-static > stuff should not be > marked as deprecated in the 1.6 branch. [SNIP] So we should pre-deprecate them, i.e. "This will be deprecated in a future version."? ;) -Matt _

Re: sync FileUtils

Matt Benson wrote: There is a lot of stuff in FileUtils that is marked for Ant 1.7 but that is already in use in Tasks that have small changes that would be good 1.6.3 candidates. The FileUtils changes in question (I may have missed some): static getFileUtils() method (Martijn) files comparison

sync FileUtils

There is a lot of stuff in FileUtils that is marked for Ant 1.7 but that is already in use in Tasks that have small changes that would be good 1.6.3 candidates. The FileUtils changes in question (I may have missed some): static getFileUtils() method (Martijn) files comparison ignoring line

FileUtils

Would it seriously break backwards compatibility to make the current FileUtils a static class? Looking at Expand earlier, I noticed several protected methods that passed a FileUtils object as a parameter, if the FileUtils class was static we could do away with a parameter being passed all the

Purpose of FileUtils.close(...) (was: Re: [Patch] FileUtils more minor changes)

Kev Jackson wrote: As an aside, I went through the entire codebase last night and replaced every try { somthing.close() } catch (IOException e) { //swallow exception } with FileUtils.close() So what exactly *is* the intention of this method? IMHO, if an IOException was thrown when some strea

[Patch] FileUtils more minor changes

- new generic close method - reduces duplicate code (may be useful for when we can finally remove code -> Ant2?) - minor loop tweak - buffer compare for JDK1.4+ (only runs on files < 1Mb to conserve memory during builds) +int stackSize = s.size(); while (tok.hasMoreTokens()) {

Re: [Patch] FileUtils to use own close method

On Mon, 13 Dec 2004, kj <[EMAIL PROTECTED]> wrote: > -FileUtils now uses close to close inputstreams inside itself I've applied this part of the patch, but have some more comments on the rest: > +int stackSize = s.size(); > while (tok.hasMoreTokens()) { &

Re: [Patch] FileUtils to use own close method

On Tue, 2004-12-14 at 10:40 +0100, Stefan Bodewig wrote: > That's why we have conditional compilations in Ant's build file - but > we can't compile a core service like FileUtils on JDK 1.4+ only. OK, thanks

Re: [Patch] FileUtils to use own close method

the Jdk14Regexp* classes. That's why we have conditional compilations in Ant's build file - but we can't compile a core service like FileUtils on JDK 1.4+ only. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] F

Re: [Patch] FileUtils to use own close method

On Mon, 2004-12-13 at 10:42 +0100, Stefan Bodewig wrote: > On Mon, 13 Dec 2004, kj <[EMAIL PROTECTED]> wrote: > > > -added new private method to use java.nio memory mapped files > > Ant is JDK 1.2 compatible, which means we can't use NIO for core > functionality (at least not without falling back

Re: [Patch] FileUtils to use own close method

On Mon, 13 Dec 2004, kj <[EMAIL PROTECTED]> wrote: > -added new private method to use java.nio memory mapped files Ant is JDK 1.2 compatible, which means we can't use NIO for core functionality (at least not without falling back to reflection). Stefan ---

[Patch] FileUtils to use own close method

-FileUtils now uses close to close inputstreams inside itself -added new private method to use java.nio memory mapped files for contentEquals method (this implementation doesn't care how large the files are, it simply tries to map the entire file, perhaps it would be better to check file

Re: cvs commit: ant/src/main/org/apache/tools/ant/util FileUtils. java

Dominique Devienne wrote: From: Steve Loughran [mailto:[EMAIL PROTECTED] You can probe for NTFS by creating a file with a stream. e.g foo.txt:1 And how do you create a file with a stream in Java Steve? --DD Just open a file with that name? File f=new File("c:\foo.txt:1"); -

RE: cvs commit: ant/src/main/org/apache/tools/ant/util FileUtils. java

> From: Steve Loughran [mailto:[EMAIL PROTECTED] > You can probe for NTFS by creating a file with a stream. e.g > foo.txt:1 And how do you create a file with a stream in Java Steve? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED

Re: [patch] [vms] updates to Exec, DirectoryScanner, and FileUtils

Stefan, > > I have been working a little bit again to get Ant to run on > > OpenVMS. > > Thanks, patch committed with some slight indentation changes (if only > you could stop using tabs 8-). Cool. I'll try :-) --knut - To u

Re: [patch] [vms] updates to Exec, DirectoryScanner, and FileUtils

On Tue, 23 Sep 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote: > I have been working a little bit again to get Ant to run on > OpenVMS. Thanks, patch committed with some slight indentation changes (if only you could stop using tabs 8-). Stefan ---

[patch] [vms] updates to Exec, DirectoryScanner, and FileUtils

updates to the documentation for . DirectoryScanner now also works in case sensitive mode on OpenVMS . I added a method FileUtils#toVMSPath(File) which returns a VMS style path for a Unix style path. This method isn't used internally yet, but should be used in the future for I hope to be

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

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

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

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 shou

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

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 thi

RE: FileUtils#normalize(File)

> > 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 c

RE: FileUtils#normalize(File)

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).

Re: FileUtils#normalize(File)

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 fo

Re: FileUtils#normalize(File)

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 c

RE: FileUtils#normalize(File)

> > > 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'

Re: FileUtils#normalize(File)

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 Symb

RE: FileUtils#normalize(File)

> > > 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 >

Re: FileUtils#normalize(File)

- 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

FileUtils#normalize(File)

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 think it makes perfectly sense to normalize a path

Re: FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

On Tue, 24 Jun 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > Reason : the jar tests are failing with temporary files which cannot > be renamed when I try the change. Interesting - are those files locked? Stefan - To u

Re: FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

Hi Stefan and others, I will shy away from changing the implementation of FileUtils#createTempFile from what it is now to a pure wrapper of File#createTempFile. Reason : the jar tests are failing with temporary files which cannot be renamed when I try the change. I will just use

Re: FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

On Mon, 23 Jun 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > The JavaDoc concerning FileUtils#createTempFile said : > > >>This method is different to File.createTempFile of JDK 1.2 as it doesn't > create the file itself and doesn't use platform speci

Re: FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

Hi Stefan, OK, I will try this [using File#createTempFile inside FileUtils#createTempFile]. The JavaDoc concerning FileUtils#createTempFile said : >>This method is different to File.createTempFile of JDK 1.2 as it doesn't create the file itself and doesn't use platform sp

Re: FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

On Fri, 20 Jun 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > Why do we not use java.io.tmpdir ? JDK 1.1 legacy - we'd probably better go the full way and use File#createTempFile in that method if you are going to change it - and change the Javadocs appropriately (as the file will get cr

Re: FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

peter reilly wrote: I think java.io.tmpdir is not used because it is not in java 1.1. As Ant does not support 1.1 (except to generated 1.1 classes), use should probably be made of java.io.File#createTempFile(). yes, the tempFile stuff was there for 1.1 support; same with the touch stuff ---

Re: FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

hat when one does not specify a directory to create a temp > file > (argument parentDir=null) > the method FileUtils#createTempFile public File createTempFile(String prefix, > String suffix, File parentDir) > creates the temp file in the current directory. > Why do we not use ja

FileUtils#createTempFile : what about using java.io.tmpdir as a default there ?

that when one does not specify a directory to create a temp file (argument parentDir=null) the method FileUtils#createTempFile public File createTempFile(String prefix, String suffix, File parentDir) creates the temp file in the current directory. Why do we not use java.io.tmpdir ? Cheers

DO NOT REPLY [Bug 19979] - FileUtils removeLeadingPath method

gzilla/show_bug.cgi?id=19979 FileUtils removeLeadingPath method [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Reso

DO NOT REPLY [Bug 19979] New: - FileUtils removeLeadingPath method

gzilla/show_bug.cgi?id=19979 FileUtils removeLeadingPath method Summary: FileUtils removeLeadingPath method Product: Ant Version: 1.5.2 Platform: All URL: http://nagoya.apache.org/gump/javadoc/ant/build/javadocs /org/apache/too