Bug 138071 - "Save remote" fails with "This operation is not supported on this operating system"
Summary: "Save remote" fails with "This operation is not supported on this operating s...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:7.3.0 target:7.2.3
Keywords: bibisected, bisected, regression
: 139132 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-11-08 12:51 UTC by Dietmar
Modified: 2021-10-18 18:46 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dietmar 2020-11-08 12:51:35 UTC
Message:

Error saving the doument [docs-name]:  This operation is not supported on this operating system
Message quite similar to Bug 121780

Situation: 
New or locally existing document in LibreOffice Writer shall be saved using File / "Save remote" here depending on SSH protocol (sftp internally). 
This file was not opened via File / Open Remote. 

Independently reproducible in same LAN(IPv4) or remote WAN (IPv6) on different machines. All machines are physical, OS is Linux U20.x. SSH settings are existing successful for several month. Host machine uses OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020; Client uses Libre Office 7.0.2.2 or Libre Office 6.4.6.2
 

Issue does NOT appear if a document is already opened via File / Open Remote and then saved under same name using File / "Save remote" (identical connection settings). 

- What can I do to provide logs, generate dumps etc in this case (I can handle CLI but am no developer)
- if this is a bug what can be done to support a fix?
Comment 1 Petr Valach 2020-11-11 17:39:37 UTC
I have exactly the same problem. I use SFTP transfer.
Version: 7.1.0.0.alpha1
Build ID: 987671387712c4f9061d6216ff2f001a7bb9e57b
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 2 Justin L 2021-10-15 13:38:10 UTC
I can reproduce this.
I note that the save actually DOES occur once you get past all the error messages.

This looks like it can be fixed by changing
ucb/source/ucp/gio/gio_content.cxx getPropertyValues IsDocument and IsFolder's
            getFileInfo(xEnv, &pInfo, /*failOnError=true*/false);
Comment 3 Justin L 2021-10-16 09:57:42 UTC
It was working in 6.1. It didn't save at all in 6.2.0 (with 5 error messages) starting with commit ca0308797df86ebece19260f3ca438a0cb437208
Author: Stephan Bergmann on Tue Nov 13 08:13:00 2018 +0100
    tdf#121337: Fail on GIO error in GIO UCP getPropertyValue

The saving part was fixed in 6.2.4 (with only 3 error messages, but save works) starting with commit 41747b75076e4446947873b3edc2abe3e3c4ebd1
Author: Stephan Bergmann on Mon Apr 29 11:45:46 2019 +0200
    tdf#123472: Propagate getGFileInfo failure less aggressively

There are still 3 errors in 7.3 (as the system looks to see if the file already exists before overwriting it).
Comment 4 Justin L 2021-10-16 18:43:12 UTC Comment hidden (off-topic)
Comment 5 Justin L 2021-10-18 04:52:20 UTC
*** Bug 139132 has been marked as a duplicate of this bug. ***
Comment 6 Justin L 2021-10-18 18:46:36 UTC
fix in 7.3 and 7.2.3 with
commit 15d0eec26be416e77d9b9580cf34d9a1d32a2615
Author: Caolán McNamara on Mon Oct 18 13:01:05 2021 +0100
    Related: tdf#145169 unwanted dialogs on sftp save to remote to a new document