Normalize computation of directory and file-in-directory URLs

There are occasional failures of Jenkins "Daily Screenshot Build on Windows"
like <https://ci.libreoffice.org/job/lo_tb_master_win_screenshot/324/console>
and <https://ci.libreoffice.org/job/lo_tb_master_win_screenshot/332/console>,
always failing with

> C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win_screenshot/test/source/screenshot_test.cxx(84) : error : Assertion
> Test name: ReportdesignDialogsTest::openAnyDialog
> assertion failed
> - Expression: aNew.IsOpen()
> - Failed to open <C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win_screenshot/workdir/screenshots/modules/dbreport/ui/condformatdialog/CondFormat.png>: 796

(where 796 is ERRCODE_IO_NOTEXISTSPATH).  Beats me how that can happen, when
ScreenshotTest::implSaveScreenshot first creates the dir and then the file-in-
dir (and it is rather unlikely that something else deletes the dir in the
meantime, for various builds of that Jenkins bot, always for the same dir
workdir/screenshots/modules/dbreport/ui/condformatdialog/), and why it always
happens for exactly the same file,
workdir/screenshots/modules/dbreport/ui/condformatdialog/CondFormat.png during
CppunitTest_reportdesign_dialogs_test.

However, one curiosity was that the dir's URL was computed with

m_directories.getURLFromWorkdir(aDirname);

(without a leading slash inserted before aDirname) while the file's pathname was
computed with

m_directories.getPathFromWorkdir("/" + aDirname + ...)

(with a leading slash inserted before aDirname).  Turns out that SvFileStream
accepts a URL as well as a pathname, so normalize the computation of the dir's
and the file's URL.  Maybe that will give a clue why that Jenkins bot sometimes
fails.

Change-Id: I53b59b51ffc4355c45aa0ca72f6e187cf2010f92

0 files changed, 0 insertions, 0 deletions