GNOME Bugzilla – Bug 690524
Fix reading from OLE files not multiple of block size
Last modified: 2013-02-23 02:05:36 UTC
Some files are not multiple of block size in size. Reading the last block currently fails. A few misc. patches are also added in the series as bonus.
Created attachment 231928 [details] [review] ole: update OLECF specification link
Created attachment 231929 [details] [review] ole: factour out seeking to block
Created attachment 231930 [details] [review] ole: only read amount needed from block Some OLE files are not multiple of block size, and may file to read the last block when its size is smaller.
Created attachment 231931 [details] [review] ole: round-up the number of blocks Some files are not multiple of block size, we may still want to seek to the last block
Created attachment 231932 [details] [review] ole: fix TODO to avoid extra copy when reading
I have committed the first two parts. What generates such files with a partial final block? Can you attach a sample, please?
It's a bit large to copy here: It came from the GStreamer merge modules. I tried to read the base-system-2012.11-x86.msm (which I want to read with msiinfo from msitools): http://cdn.gstreamer.com/windows/x86/gstreamer-sdk-x86-2012.11-merge-modules.zip Note that "gsf dump" will succeed, since it reads only the amount needed and not multiple of block size (the blocks are consecutive). Otoh, msitools reads by chunks and will hit that bug.
> Otoh, msitools reads by chunks and will hit that bug. Doesn't that basically mean that the file is broken and that GStreamer has a bug it needs to fix? (I hope GStreamer didn't use libgsf to write it!)
(In reply to comment #8) > > Otoh, msitools reads by chunks and will hit that bug. > > Doesn't that basically mean that the file is broken and that GStreamer > has a bug it needs to fix? (I hope GStreamer didn't use libgsf to write it!) I am pretty sure they used microsoft MSI tools, since there is nothing else out there. But tbh, I don't see how the patch would hurt anyway, and would still be compatible with "broken files"
One more point in favour of fixing this, the Microsoft tools (Orca and msi* programs, installer..) have no issue dealing with those files.
Morten, I believe the patch is not going to break any usage, it will only limit the read to what is actually needed. Even if the sector to read is not of sector-size, I don't think there is a valid argument to not allow that read. I hope that can convince you. If not, we will sadly not be able to read some existing files out there, although other tools, including from Microsoft, do accept it fine. A warning could be useful though. Would you accept an updated patch with that?
I'll get around to it.
Hi Morten, I believe those patches are worth not being ignored. thanks again
They aren't being ignored. With only 14 open bugs, they also will not fall through the cracks. It'll happen sometime before the next release.
cool, thanks
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.