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=32649>. 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=32649 ------- Additional Comments From [EMAIL PROTECTED] 2004-12-20 08:37 ------- (In reply to comment #8) > We can handle a delay, after all, we have no schedule for the next release. > One question: are you trying to look for a magic number at an offset in the > binary, or are you parsing the zip file? > > A magic number pattern is most like classic unix exe lookup, but is > inordinately > brittle against different legitimate layouts of ZIP files. You should really > be > recognising the PK DWORD at the beginning of the file and say 'this is a zip, > lets look inside it *using the zip algorithm* and see if it has a manifest. > > Presence of a valid manifest is what should really determine if a jar is > executable. If that aint there, you wont know which class to execute, etc, > etc. > Since we do produce valid manifests if asked to, that should all work. Thanks for your patience. The algorithm as it stands is as follows: The kernel decides to use the 'javaexec' file executor based on magic number (same as with ELF and interpreted files, like #!... ). Based on the magic number (PK\003\004), the javaexec module is invoked. My reading of the code is as follows: 1. Read the 30 byte file header. 2. Look for 'PK\003\004' at the beginning. If not, fail. 3. Let XOFF = 30 (file header size) + Size of the first file's name (stored at offset 26). So, if the first file is META-INF/, XOFF = 9. 4. Let XOFF_END = XOFF + Size of the first file's extension. Normally this would be zero, but in this case, the jar tool seems to set it in the archive to '4'. 5. Scan the buffer starting at XOFF and ending at XOFF_END for the byte pattern: 0xcafe. If not found, fail. 6. Find and invoke the Java runtime environment on the file. I can only assume that the answer to: "why not scan the whole file for the manifest file" is that this would be rather expensive, although I'm not sure. If you mean that we should also unzip the manifest file and parse it-- I think the answer is that we try not to sink that level of complexity into the kernel. -- 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]
