DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35776>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/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 since > we all stumble daily over those and JVMs haven't delivered on this so far, why > not aiming for the second best and giving it a (temporary) home in the jakarta > family of projects? (instead of everybody making his own > half-hearted-quick-fixes all the time) One idea: extend oata.types.FileSet -> CygwinFileSet (e.g.), which returns an extended oata.DirectoryScanner that knows how to resolve cygwin symlinks. The result is a drop-in replacement for fileset (using typedef though I know Steve L. will complain ;) and any compatibility risks are undertaken voluntarily by the user. > Also, "This means that any code we wrote ... might not work against older or > future versions of ..." - isn't that true for almost any interface/third-party > component one programs against/with? Indeed; however most third-party components do not masquerade as the filesystem. By the way, don't get me wrong here. I have been a loyal cygwin user for quite some years now. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
