Move dubious file: -> smb: conversion from INetURLObject to file UCP
The Linux-only conversion of file URLs with a non-empty (other than "localhost") authority to smb URLs had been added in 2010 with 0b9ef81b "tools-urlobj-smb-scheme-patch.diff: migrated" (applying a Go-oo patch?) but giving no rationale beyond "process relative SMB paths (in hyperlinks) correctly". That makes it hard to tell whether that patch is (still) actively useful for anything, or was just a misguided hack from the beginning: * Why make this Linux only? What about other non-Windows OSs? (On Windows, such URLs can be resolved as UNC pathnames.) If the reason for Linux-only was that it is the only OS where LO can handle smb URLs via GIO, why not make it conditional on ENABLE_GIO? * Why map to smb? There are various remote file access protocols. Hardcoding smb looks arbitrary here. Anyway, INetURLObject is arguably at a wrong level for such a patch. To not drop the hack wholesale, reimplement it in the file UCP, forwarding to a potential other UCP that can handle smb URLs any file://<host>/... URLs (rewritten as smb URLs) that the file UCP cannot handle itself. (file://localhost/... URLs will already have been normalized to file:///... by INetURLObject when they reach the file UCP, and even if they were not, the osl/file.hxx functionality underlying fileaccess::TaskManager::getUnqFromUrl knows how to handle them, so they will not take the forward-to-smb code branch.) (The corresponding #ifdef WIN code from 0b9ef81b has already been removed with 82034b04 "tdf#119326 crash when adding "Windows Share" File resource".) (I came across that 2010 patch while looking into <https://bugs.documentfoundation.org/show_bug.cgi?id=107461> "Does not support 'file://' scheme with actual hostname". A next step would be to make the file UCP actually handle any file://<host>/... URLs that denote the local host.) Change-Id: I77242705dc4c6c1e9cb3a4f32253224ac6cb13cb Reviewed-on: https://gerrit.libreoffice.org/67372 Tested-by: Jenkins Reviewed-by:Stephan Bergmann <sbergman@redhat.com>
Showing
Please
register
or
sign in
to comment