Saving a Writer document containing an inaccessible UNC link as HTML takes 33 seconds on Windows because of the following call to FindFirstFileW in core\sal\osl\w32\file_dirvol.cxx:1084: hFind = FindFirstFileW( o3tl::toW(rtl_uString_getStr(strSysFilePath)), &aFindData ); (https://git.libreoffice.org/core/+/refs/heads/libreoffice-7-0-4/sal/osl/w32/file_dirvol.cxx#1084) FindFirstFileW does not return for about 33 seconds. It then returns 0xffffffffffffffff. GetLastError() returns ERROR_BAD_NETPATH (53) which is translated to osl_File_E_NOENT. The call occurs while normalizing the links contained in the document before saving it as HTML: > sal3.dll!osl_getDirectoryItem(_rtl_uString * strFilePath, void * * pItem) row 1084 C++ > [Inlineframe] ucpfile1.dll!osl::DirectoryItem::get(const rtl::OUString &) row 1529 C++ > ucpfile1.dll!fileaccess::TaskManager::getv(long CommandId, const rtl::OUString & aUnqPath, const com::sun::star::uno::Sequence<com::sun::star::beans::Property> & properties) row 1083 C++ > ucpfile1.dll!fileaccess::BaseContent::getPropertyValues(long nMyCommandIdentifier, const com::sun::star::uno::Sequence<com::sun::star::beans::Property> & PropertySet) row 687 C++ > ucpfile1.dll!fileaccess::BaseContent::execute(const com::sun::star::ucb::Command & aCommand, long CommandId, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & Environment) row 302 C++ > svllo.dll!`anonymous namespace'::normalizePrefix(const com::sun::star::uno::Reference<com::sun::star::ucb::XUniversalContentBroker> & broker, const rtl::OUString & uri, rtl::OUString * normalized) row 149 C++ > svllo.dll!`anonymous namespace'::normalize(const com::sun::star::uno::Reference<com::sun::star::ucb::XUniversalContentBroker> & broker, const com::sun::star::uno::Reference<com::sun::star::uri::XUriReferenceFactory> & uriFactory, const rtl::OUString & uriReference) row 180 C++ > svllo.dll!URIHelper::normalizedMakeRelative(const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & context, const rtl::OUString & baseUriReference, const rtl::OUString & uriReference) row 264 C++ > svllo.dll!URIHelper::simpleNormalizedMakeRelative(const rtl::OUString & baseUriReference, const rtl::OUString & uriReference) row 273 C++ > swlo.dll!SwHTMLWriter::convertHyperlinkHRefValue(const rtl::OUString & rURL) row 1260 C++ > swlo.dll!SwHTMLWriter::OutHyperlinkHRefValue(const rtl::OUString & rURL) row 1265 C++ > swlo.dll!OutHTML_INetFormat(Writer & rWrt, const SwFormatINetFormat & rINetFormat, bool bOn) row 3017 C++ > swlo.dll!OutHTML_SwFormatINetFormat(Writer & rWrt, const SfxPoolItem & rHt) row 3076 C++ > swlo.dll!Out(Writer &(*)(Writer &, const SfxPoolItem &) * pTab, const SfxPoolItem & rHt, Writer & rWrt) row 40 C++ > swlo.dll!`anonymous namespace'::HTMLEndPosLst::OutStartAttrs(SwHTMLWriter & rHWrt, long nPos, HTMLOutContext * pContext) row 1935 C++ > swlo.dll!OutHTML_SwTextNode(Writer & rWrt, const SwContentNode & rNode) row 2427 C++ > swlo.dll!SwHTMLWriter::Out_SwDoc(SwPaM * pPam) row 834 C++ > swlo.dll!SwHTMLWriter::WriteStream() row 471 C++ > swlo.dll!Writer::Write(SwPaM & rPaM, SvStream & rStrm, const rtl::OUString * pFName) row 272 C++ > swlo.dll!Writer::Write(SwPaM & rPam, SfxMedium & rMedium, const rtl::OUString * pFileName) row 286 C++ > swlo.dll!SwWriter::Write(const tools::SvRef<Writer> & rxWriter, const rtl::OUString * pRealFileName) row 859 C++ > swlo.dll!SwDocShell::ConvertTo(SfxMedium & rMedium) row 782 C++ > sfxlo.dll!SfxObjectShell::SaveTo_Impl(SfxMedium & rMedium, const SfxItemSet * pSet) row 1553 C++ > sfxlo.dll!SfxObjectShell::DoSave_Impl(const SfxItemSet * pArgs) row 2565 C++ > sfxlo.dll!SfxObjectShell::Save_Impl(const SfxItemSet * pSet) row 2635 C++ > sfxlo.dll!SfxBaseModel::storeSelf(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aSeqArgs) row 1631 C++ > sfxlo.dll!SfxBaseModel::impl_store(const rtl::OUString & sURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & seqArguments, bool bSaveTo) row 2994 C++ > sfxlo.dll!SfxBaseModel::storeAsURL(const rtl::OUString & rURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & rArgs) row 1685 C++ >... Steps to reproduce: 1. Open LibreOffice Writer 7.0.4.2 on Windows 10 2. insert a UNC link to a reachable but inacessible shared folder (e.g. "\\foo.bar.net\some_directory\another_directory") 3. Save document as "HTML Document (Writer)" Unfortunately, I am currently unable to provide an example link. All examples known to me are only available inside private networks. They all feature host names which can be resolved via DNS and react to pings but time out when trying to access them with Chrome or the Windows Explorer. Is there a way to normalize the links without sending requests to the associated resources? All it seems to do in my case is to turn backslashes into slashes.
Thomas, unfortunately nothing has happened with this bug report for more than half year. So I'd like to ask, if it is still valid. Could you please try to reproduce it with the latest version of LibreOffice? => NEEDINFO
Hello Dieter, I have retested this issue with LibreOffice 7.1.6.2. LibreOffice still hangs when saving the document, but only for 12 instead of 33 seconds. (This could be a result of changes in the network configuration of my test environment.) The call to FindFirstFileW is still there at https://git.libreoffice.org/core/+/refs/heads/libreoffice-7-1-6/sal/osl/w32/file_dirvol.cxx#1084. So one would expect the issue to also still be there if the theory that it is caused by this call is valid.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Thomas K from comment #0) > Is there a way to normalize the links without sending requests to the > associated resources? All it seems to do in my case is to turn backslashes > into slashes. This is not a correct idea: normalizing is not only "turning backslashes into slashes", it is also e.g. converting short 8.3 names into full names, and getting proper case of the path parts (important in case-insensitive systems, where multiple ways to represent the same path may make it impossible to compare paths, including checks for common root, important for producing relative URLs). (In reply to Thomas K from comment #2) > The call to FindFirstFileW is still there at > https://git.libreoffice.org/core/+/refs/heads/libreoffice-7-1-6/sal/osl/w32/ > file_dirvol.cxx#1084. So one would expect the issue to also still be there > if the theory that it is caused by this call is valid. Of course, it is correct that this is *only a theory*, and it needs to be tested regardless if the call is there or not: the said call is in osl_getDirectoryItem, some low-level LO API, and the higher-level APIs could (*in theory* :-D) start to use other low-level APIs - see e.g. tdf#98705, where we made some changes to the WinAPI calls we perform when get case-correct file paths - even though unrelated to this case, it shows that changes on different levels can affect the result. Possibly this should be NOTABUG, since calculation of relative links is correct and inevitable for case when you *save* (i.e., define new path) a document with relative links, and there's no way to normalize paths without getting that data from OS/filesystem, at which point, file access happens.
(In reply to Mike Kaganski from comment #4) > Possibly this should be NOTABUG, since calculation of relative links is > correct and inevitable for case when you *save* (i.e., define new path) a > document with relative links, and there's no way to normalize paths without > getting that data from OS/filesystem, at which point, file access happens. Mike, you should decide, if it is NOTABUG?
(In reply to Dieter from comment #5) In comment 4, I explained the need to re-test this. It could be WORKSFORME, after all. Unfortunately, that hadn't been done. There could possibly be some ways to improve it - e.g., specific to case when the save happens to the same file, so no change of relative links happens (which is likely the majority of cases) ... I dislike to close bugs like this, because someone could have good ideas, not obvious to me. Only when it's very obvious that the idea is wrong, I close in such cases.