ZipFileExt.read() can return more data than requested, unlike file and other file-like objects. This function calls read1() in a loop, passing the original requested size even if part of the data was already read thus reading and returning more than the caller requested. This should be fixed by requesting n-len(buf) or something similar, or at least properly documented.
Indeed. In most cases, though, read1(n) will return exactly n bytes and the loop will therefore end immediately with the right buf size. Do you have a simple test case?
If i follow the logic in read1() correctly it will do that only for files with very low compression ratios (the original sample where i noticed that problem was actually a chunk of encrypted data inside the zip). From the comments referring to "with at most one read() system call" I would also assume it's OS-specific. Anyway, I've attached a small file that reproduces this behavior on my system (win xp 32bit). When i run it i get "AssertionError: Read returned 4097 bytes (4096 requested)"
