Hi, CRASH with option - general - USE DIALOG BOX Libo if folder contains a file with Pipe car. Requirements : - I have a linux server with a folder containing a file with a PIPE char. like, for example : "test file | that cause crash.txt" - This folder is shared with my WIN7 client. When the option : Tools - Options - General - [X] use dialog box of libo is checked. trying to save a file in this folder cause a CRASH. No problem if I UNCHECK this option or I remove the "|" pipe char in the filename.
How did you manage to make Samba to show a name with a pipe while sharing? It just shows a scrambled filename for this file for me.
It's not really a samba share I think (don't know). The file is present on my linux host and I share it with shared folder option in VirtualBox. The problem for me is that when I use system UI and not lodev ui, it's working. I admit that file with "|" are not mine, only resultat from a file - save of internet page ;-)
I have just tested it on samba. And You're right, my file or folder with "|" char, kept the first letter but the rest of character is converted to 8 character <six character>~1 So I think problem is linked only to VboxSharing ...
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=588997f0ebc5696574680098b128e66eff54f00c fdo#58415: Don't ignore osl_getFileURLFromSystemPath failure The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The above commit fixes the problem in that it no longer causes a crash when browsing the LO-internal file dialog to the directory containing the file with "|" in its name. That file is still displayed as an odd element with an empty name, though. Requested backporting the fix to libreoffice-4-0 (<https://gerrit.libreoffice.org/#/c/1719/>) and libreoffice-3-6 (<https://gerrit.libreoffice.org/1720>).
Very unlikely it'll be backported to 3.6 but 4.0 should be able to happen
(In reply to comment #6) > Very unlikely it'll be backported to 3.6 What makes it unlikely to be backported into 3.6.6?
I thought only security related stuff is being backported (or really serious patches) -- but you'd know more than I do :)
@Joel: There's no restriction on what type of patches can go in. If a fix is sane and uncontroversial and gets a reviewer's ok then we'll have it.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bcc204783bf5539570af2bbb49ac0b3f337ae70d&h=libreoffice-3-6 fdo#58415: Don't ignore osl_getFileURLFromSystemPath failure It will be available in LibreOffice 3.6.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1839f7be0a6720c11086df00a50443fe8ee3bd00&h=libreoffice-4-0 fdo#58415: Don't ignore osl_getFileURLFromSystemPath failure It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.