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)"

Ok, thank you. I've fixed the issue and added a test in r84737 (3.x) and r84739 (2.7).