Re: [widgets] Zip endian issue?

Well,

the ZIP file specification does say that all values are stored in little-endian byte order unless otherwise specified. The local file header signature is the four bytes 50 4B 03 04, in this order, always. Endianness is not even an issue, if you read and compare individual bytes.

How could the ZIP file "be entirely transposed on media"? It is a binary file; if some entity is "transposing" it, it's not the same file anymore. A practical example of where and how this would be happening is needed.

--Jere


On 3.4.2009 11.54, "ext Marcos Caceres" <marcosc@opera.com> wrote:

Hi,
I recently chatted with Josh and he pointed out that there might be an
endian issue when checking for magic numbers.
[[
timeless.bmo1@gmail.com:  zip files are guaranteed not to have ENDIAN issues?
If the first four bytes of the potential Zip archive do not match the
magic numbers for a Zip archive (50 4B 03 04)
 me:  ah, good point
 timeless.bmo1@gmail.com:  i.e. could you have 4B500403
or whatever the correct endian corruptions are :)
 me:  All values
 are stored in little-endian byte order unless otherwise specified.
 timeless.bmo1@gmail.com:  yeah, but could the file be entirely
transposed on media
test it.. create a zip file w/a single tiny file and then use some
perl magic to swap each pair of bytes :)
(i'm not awake enough to do that)
 me:  neither am I
]]

Anyone with experience in this area want to propose some text for the
P&C spec to fix this issue.

Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au