Problem description: Steps to reproduce: 1. Open this file. Problem is the file is 380 megs(so I am not sure the upload will work). Occasionally after saving the file no longer can be opened by libre office. Current behavior: Cannot open or repair the file. Expected behavior: The file is successfully opened. Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
(In reply to comment #0) > Problem description: > > Steps to reproduce: > 1. Open this file. Problem is the file is 380 megs(so I am not sure the upload > will work). No, bugzilla does not accept attachments this large. If you want to make the file accessible to us, you have to upload it somewhere and put a link here.
OK, I uploaded it here: https://docs.google.com/open?id=0BwSC4GtrkHpNWkw0cG8tZHhPdDA It should come out as BS2012.odp It is a slide show of a bunch of jpegs(200-300). Not sure a)why it got so large, or b)why it occasionally saves such that it cannot open. "a" may of course be user error, pretty sure "b" isn't.
md5sum BS2012.odp 5458e70fd30ec59f7e8772135069ee4a BS2012.odp right ? unzip -l doesn't work on that either. So broken at the .zip level. zip -FF BS2012.odp --o out.odp recovers the .jpg files anyway, but not the content.xml etc, i.e. output is still broken as an .odp but not as a .zip
Right. md5sum (GNU coreutils) 8.14 5458e70fd30ec59f7e8772135069ee4a BS2012.odp
It seems truncated to me. I'd *guess* that when it hits a certain size on save then it gets truncated for "some reason", i.e. the bug is on save rather than load. Clearing needinfo as the result of the error is now available.
This error happened three times before we changed slide show methods. Large numbers of pics were added per session then started over when the previous days work couldn't be opened. So I cannot add more granular information. Perhaps there is a list of assets that are supposed to be in the file that can be compared to the actual number of jpgs?
The joy of the .zip format is that the table of entries is at the end :-), so we lose the table of what's in it on truncation. I might try and see by just adding bad pictures to a working presentation if I can hit upon a size that starts failing to save correctly.
OK I see. I was hoping perhaps there was an XML file or something for LibreO that listed all the pics along with their formatting or something. Thanks for looking into it, it is a super annoying bug, literally wrecked over 24+ hours of work.
And I don't know if this matters, but it was a Win7 workstation onto a Samba share.
Successfully created a 500+meg plus presentation without truncation, so its not a fundamental limit bustage. Is there sufficient local free diskspace for the temporary files ?, i.e. >= 2/3 gigs ?
Absolutely. There is over 50 gigs free.
By writing to a "too small" loopback file system I can confirm that LibreOffice sticks up a "failed to write" dialog anyway, so failures to write appear to be reported and not silently ignored. So I got nothing :-) Would be interesting to see if it can be reproduced on saving to a local file system, to rule out that its bustage on the network file system with huge documents. FWIW the sizes are reasonable in that each jpg is about 2 megs in size and with 150+ of them then 300megs for the presentation is sane
WORKSFORME ?! OSX 10.9.4 LO Version: 4.3.1.1 Build ID: c4b15cd4d00dec6b266fa830b4ba73e31ae6ce73 I open testfile in question. LibreOffice says file is correct and asks "Should I repair that thing?" Me says "Yes" LibreOffice opens repaired file. Me sees empty presentation. So now what? Put this WORKSFORME. Please reopen with more detail if that is not what you expect LO to do.