summaryrefslogtreecommitdiff
path: root/sysui/Module_sysui.mk
diff options
context:
space:
mode:
authorMike Kaganski <mike.kaganski@collabora.com>2023-12-01 16:48:44 +0300
committerMike Kaganski <mike.kaganski@collabora.com>2023-12-01 16:13:38 +0100
commita5a49657dc17609a05dca59a8521fd71d14fe76e (patch)
treeb5d6e1f0df0d3da94135fc833bd5ef027d15a992 /sysui/Module_sysui.mk
parent8a0015c35f3f137e4f3a80e40616bc078e265a1c (diff)
tdf#158442: fix opening hybrid PDFs on Windows
Commit 046e9545956d8ad1d69345d6b4a4c0a33714d179 (Try to revert to use of file_iterator from boost on Windows, 2023-10-31) had introduced a problem that pdfparse::PDFReader::read couldn't create file_iterator for files already opened with write access: mmap_file_iterator ctor on Windows used single FILE_SHARE_READ as dwSharedMode parameter for CreateFileA WinAPI; and that failed, when the file was already opened using GENERIC_WRITE in dwDesiredAccess - which happens when opening stream in TypeDetection::impl_detectTypeFlatAndDeep. Fix this by patching boosts' mmap_file_iterator constructor to use FILE_SHARE_READ | FILE_SHARE_WRITE, like we do in osl_openFile. But there was a pre-existing problem of using char-based CreateFileA API, which disallows opening any files with names not representable in current Windows codepage. Such hybrid PDF files would still fail creation of the file_iterator, and open as PDF. Fix that by further patching boost to have wstring-based constructors for file_iterator and mmap_file_iterator on Windows, which would call CreateFileW. Change-Id: Ib190bc090636159ade390b3dd120957d06d7b89b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160218 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Diffstat (limited to 'sysui/Module_sysui.mk')
0 files changed, 0 insertions, 0 deletions