This is a Windows-specific bug. When browsing on a slow FS, typicaly a network file system, Windows Explorer hang while loading the thumbnails.
This problem is seen on a Novell Storage Services (NSS, or ncpfs on Linux). A network capture shows that file is read one byte at a time. Digging further, I found that shell/source/win32/shlxthandler/thumbviewer/thumbviewer.cxx load a ZipFile (line 360) and then call GetUncompressedContent on it. This call readCentralDirectoryEntry several times and readCentralDirectoryEnd. Those two fuctions use readByte which "sread" one char at a time !
Created attachment 68583 [details] Patch v1 Here is a proposed patch. I cannot build yet, as my build environment is Linux only.
Created attachment 68605 [details] NCP capture Here is a network capture showing the problem. It seems that there is a problem in the Windows Netware Client : When 1byte is "sread", 512 are requested within the protocol. This looks like readahead (which is good), but when requesting the following byte, a new request is made (i.e the previous buffer was not cached).
Created attachment 68607 [details] Patch v2 Patch v1 was no removing two clear().
i'm not sure if that is a bug in the zip code or in that network file system; does the sread() not use a buffer somewhere? but it looks like it improves the code in any case with the new readString replacing numerous loops, and better error handling is also nice. there is a copy/paste error, 2 in readInt should be 4: + if (numBytesRead != 2) + throw IOException(-1); hmm... this looks like it wants to initialize a pointer with the size value? that cannot end well... perhaps better to create a real "string" with a specified size and read into that, if that is possible... + unsigned char *tmpBuf(size); it appears to me that your patch only works with one endian-ness, but given that this is win32 only code and windows only works in one endian-ness anyway that is without practical relevance. could you please send a mail with a text like http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/38402 to the mailing list libreoffice@lists.freedesktop.org ? also best to send the patch either to mailing list or to gerrit (http://wiki.documentfoundation.org/Development/gerrit) because developers look there far more often than at bugzilla for patches.
Mathieu - it'd be great to get your changes committed here - but we need a license statement on the list first ... [ which sucks ]. I'd love to get your patch in to fix the 2nd half of this problem, but the 1st half is fixed by a commit I'll make in a second.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=53138c9968e28a25a8cd6d2b5e3d31cbb3257852 fdo#56007 - fast zip directory find to accelerate Windows Explorer thumbnail. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 70224 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Mathieu - it'd be great to get your changes committed here - but we need a > license statement on the list first ... [ which sucks ]. > > I'd love to get your patch in to fix the 2nd half of this problem, but the > 1st half is fixed by a commit I'll make in a second. Hi. Done on: http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/54246
Thanks Mathieu ! I fixed up the missing ';' trailing readString, and adapted for mst's comments (thanks for the review), and pushed to master. Looking forward to your next contribution ! :-)
Mathieu Parent committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d67cd21033877c9c09d9cc4f14c2c4658e973f57 fdo#56007 - Read more bytes on Zip read (for thumbnails) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0540be231b0a10ed97da911462874a329bd089f7&h=libreoffice-4-1 fdo#56007 - fast zip directory find to accelerate Windows Explorer thumbnail. It will be available in LibreOffice 4.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mathieu Parent committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e09cfff67b021efd04235987f9c27cea3da5c72b&h=libreoffice-4-1 fdo#56007 - Read more bytes on Zip read (for thumbnails) It will be available in LibreOffice 4.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello, Is it possible to push it to libreoffice-4-0 ? And so it would be available for 4.06 version?
Perhaps a stupid question: is it possible that this bug could be related to bug 67534 since both involve the Explorer shell extension? Best regards. JBF
(In reply to comment #15) I think it is related, and this fix will solve that bug, too. If shell extension spends significantly less time on getting the metadata of the file, it will not interfere with user who double clicks on the file.
Hello, I confirm that it resolve also fdo#67534. To test you must select the file to generate the explorer thumbnail and after you have to try to open the file. Without the patch it will fail. If you open the file with DOS command by example, without selecting et generating the thumbnail it will be ok. Is there any chance to push the commit on 4.0 branch ?
(In reply to comment #17) > Is there any chance to push the commit on 4.0 branch ? since 4.0.6 was released yesterday and there are no more 4.0.x releases planned (https://wiki.documentfoundation.org/ReleasePlan/4.0) there isn't any point to doing that.