forked from amazingfate/loongoffice
a5a49657dc
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>