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] 2006-08-28 04:48 ------- (In reply to comment #3) > > Agreed, having symlinks handled by the JVM might be the best solution. > > 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. FWIW, one solution that would not involve modifying the JVM is a native method shipped with a DLL that's linked with Cygwin. That way you can guarantee that any path conversion will invoke the genuine Cygwin functionality, so compatibility will not be an issue. -- 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]
