Summary: | [FILESAVE] Saving a Writer document containing an inaccessible UNC link as HTML takes 33 seconds | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Thomas K <thomas.kraemer> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | julian.jung |
Priority: | medium | ||
Version: | 7.0.4.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: |
Description
Thomas K
2021-03-11 19:04:57 UTC
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. |