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=43558>. 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=43558 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2007-10-05 08:28 ------- (In reply to comment #3) > We aren't going to try and be clever and work it out for the end user. > There's a > good reason for that; the algorithms always get it wrong. Try, for example, to > distinguish UTF8 from iso-8859-1 or ANSI. The existing implementations only handle ASCII. > 1. We could do is add a textfiles attribute to zipfileset that tells zip to > set > the bit > > <zipfileset dir="doc" includes="**/*.txt" textfiles="true" /> > > 2. we'd need to do the same on unzip. > > 3. and write tests. This would work. > The normal best practise here is to use <fixcrlf> to force in the line endings > you want; DOS for BAT files and windows text, unix for .sh scripts, and > everything else can be left alone. This doesn't work. Unzip on both Linux and Windows and you're not getting the local line endings. -- 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]
