Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Openoffice won't open files using sftp:// in read/write mode|
|Status:||CLOSED FIXED||QA Contact:||issues@ucb <issues>|
|Priority:||P3||CC:||ccheney, issues, jnavrati, kendy, mmeeks, pagalmes.lists, rene|
|Version:||OOo 2.2 RC2|
|Target Milestone:||OOo 3.3|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
Description philippsadleder 2007-03-16 10:03:21 UTC
This bug is forwarded from Ubuntu Launchpad: https://launchpad.net/ubuntu/+source/openoffice.org/+bug/41985 Pop an openoffice document on a sftp:// 'share' under gnome, attempt to open. File will open in read-only mode, even if permissions are otherwise correct. A text-file in the same directory, will open in read-write mode with no problems in gedit, which eliminates gnome-vfs.
Comment 1 philippsadleder 2007-03-16 10:06:36 UTC
Created attachment 43737 [details] read-only check for gnomevfs
Comment 2 philippsadleder 2007-03-16 10:07:21 UTC
The attached file shows a section from OO.o source. It checks if the remote file has owner or group matches the uid/gid of the running Openoffice process (!) This is all just plain wrong: - Local and remote users/groups aren't necessarily matching. - Openoffice checks things which lay in the domain of libgnomevfs - Even if users/groups are in sync on local/remote system, there can be supplementary groups the user (on both sides) can be part of.
Comment 3 pagalmes.lists 2007-03-17 12:15:05 UTC
-> philippsadleder: Could you provide a patch for it?
Comment 4 matthias.huetsch 2007-03-19 16:11:19 UTC
Hi Andreas, can you have a look at this, please? Thanks, Matthias
Comment 5 philippsadleder 2007-03-20 09:10:43 UTC
-> pagalmes: Sorry, I cannot provide a patch at the moment. I'll maybe try to build up a patch for the issue, but for now I can only point to the code in gedit, which gets it right as far as I can tell. But I think people familiar with gnomevfs could fix this in short time. Thanks for your work, Philipp
Comment 6 pagalmes.lists 2007-03-20 09:46:01 UTC
-> philippsadleder: > But I think people familiar with gnomevfs could fix this in short time. if you know such guys, asking them to write a patch would help to solve the issue quickly. Thanks
Comment 7 philippsadleder 2007-03-21 09:54:37 UTC
I asked pbor on #gedit IRC channel for a comment on the issue: pbor: sadleder: yes, as you said those checks for uid and gid are totally bogus pbor: another difference is that gedit doesn't check at load, but on save pbor: and for saving we just save locally and transfer the file, so those kind of checks come for free pbor: in other word, we just try and if it fails we handle the exception gracefully sadleder: hmm, ok, where are files saved locally before transferring to remote? pbor: at the moment in tmp if I recall correctly pbor: with the propoer umask and stuff to protect privacy pbor: sadleder: also, did you check that you actually go past this condition: if (m_info.valid_fields & GNOME_VFS_FILE_INFO_FIELDS_PERMISSIONS) pbor: if that it is not met, do you default to writable or not writable? pbor: I seem to recall that ssh doesn't set that field pbor: so your problem may be that you default to not-writable in that case pbor: - in general I think that those kind of checks should be done lazily on save, not on load (think of the case when the perms change while the file is open), but that is a OO design decision
Comment 8 kendy 2007-03-30 12:41:07 UTC
mmeeks: You are the original author ;-) - what do you think, please?
Comment 9 mmeeks 2007-04-02 11:04:02 UTC
I think, that if there was a tested & working patch to review, then I would review it :-) but that the basic premise of returning some different value if we have no idea what the permissions are (ie. not read-only/void) is fine by me.
Comment 10 andreas.bille 2007-04-03 15:14:45 UTC
ABI->KSO: As discussed to you ...
Comment 11 kai.sommerfeld 2007-04-04 16:23:04 UTC
Comment 12 philippsadleder 2007-06-18 11:26:33 UTC
At least the main part of the issue is fixed in Debian sid (2.2.1) and Ubuntu feisty (2.2.0). What doesn't work now is opening files via sftp:// that have only read permissions. OOo reports a "common error in the internet area" (translated back from German).
Comment 13 kai.sommerfeld 2007-08-15 12:44:11 UTC
KSO->TKR: Please take care of this issue.
Comment 14 tkr 2007-08-20 09:55:45 UTC
Comment 15 kai.sommerfeld 2007-11-22 15:32:29 UTC
No time to fix this in 2.x time frame. => 3.0
Comment 16 ccheney 2008-04-25 20:09:13 UTC
Is this bug still expected to be fixed for OOo 3.0?
Comment 17 tkr 2008-04-28 08:19:25 UTC
Yes, still scheduled for OOo 3.0.
Comment 18 tkr 2008-05-27 15:01:43 UTC
I couldn't reproduce this behavior. Seems to work even with "read-only" documents. Is that only me? If I browse in a "sftp" environment with the OOo file dialog. I have noticed that OOo gets instable?! (error messages / crashes)
Comment 19 tkr 2008-06-06 13:53:50 UTC
For now I will set the issue to OOo 3.1.
Comment 20 ccheney 2008-10-17 20:06:44 UTC
It's been a while since I looked into this but if I remember correctly OpenOffice.org tries to use the same uid/gid from the local system on the remote system which doesn't work in most cases.
Comment 21 netmastr 2008-11-05 22:57:40 UTC
I have duplicated this issue in Fedora 9 on both OOo 2.4 and 3.0 offered for info purposes, will continue to monitor this issue for a solution. Need one ASAP or a workaround as I use sftp extensively. Am willing to try possible solutions as they become available to verify working/not working.
Comment 22 tkr 2008-12-09 15:58:10 UTC
No time to fix this in 3.1 time frame. => 3.2
Comment 23 netmastr 2009-02-26 20:13:41 UTC
I have been documenting the behavior in this thread: http://user.services.openoffice.org/en/forum/viewtopic.php?f=16&t=11176&start=10 The link is to page 2 of my documentation. The last couple of update posts leads me to believe that the problem may be in the way that nautilus is bringing up openoffice or possibly how openoffice handles what nautilus gives it when the the file is double clicked in nautilus.
Comment 24 gdiebel 2009-03-03 19:57:51 UTC
This also occurs when opening files over NFS mounts if the ACL restricts write to a secondary group. Works fine using ACL that require primary group membership.
Comment 25 tkr 2009-09-04 12:38:38 UTC
Sorry about that, but I cannot fix it for 3.2 -> New target 3.3
Comment 26 rlfebrero 2009-09-24 09:35:41 UTC
This also happens for me, using OOo310m11 (build 9399) on Ubuntu Hardy 8.04 LTS. It works when opening files, but fails when saving them, giving an "insufficient user permissions" error. BTW, I'm using SFTP shares: sftp://[...]. But it also happens when accessing directly from ~/.gvfs/[...] directory. All works fine when I open & save these documents (.odt, .doc, .txt...) with other applications, like Gedit. Any ideas? Are there any plans to correct this bug before 3.3? Thanks.
Comment 27 tkr 2009-09-29 09:10:48 UTC
No, not before 3.3 but it is planned to fix it with 3.3
Comment 28 tkr 2009-10-01 13:56:39 UTC
I have tried to get the access rights with passing the GNOME_VFS_FILE_INFO_GET_ACCESS_RIGHTS option to the 'gnome_vfs_get_file_info' call and then using the GNOME_VFS_PERM_ACCESS_WRITABLE permission flag to determine if the document is read only . But I haven't a clue why this doesn't work with sftp://. (fileInfo->valid_flags doesn't have the GNOME_VFS_FILE_INFO_FIELDS_ACCESS flag). If anyone has an idea please give me a hint. Otherwise i will change the behavior form eager permission check to open all documents in write mode and check permission on save to fix this issue. @rlfebrero: I cannot reproduce the behavior your described. Working with the ~/.gvfs/ directory works for me. Using sftp:// gives me read-only documents. Both on Ubuntu 9.04.
Comment 29 tkr 2009-10-07 07:37:23 UTC
Fixed as described above. All documents will be open as writable if the ucp couldn't get permission information from gvfs for any reason. If the document is only read-only the user will get a "general internet error" (sorry for this error message) during save. Fix is committed in tkr26. Maybe someone want to try it out
Comment 30 rlfebrero 2009-10-07 10:05:31 UTC
Ok, I will try ASAP (which can be never). BTW, I was using Ubuntu Hardy (8.04) with OpenOffice at the following repository: deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu hardy main
Comment 31 tkr 2009-12-07 10:58:22 UTC
TKR->TM: Please verify as described above in cws tkr32.
Comment 32 stefan.baltzer 2010-02-08 11:26:55 UTC
Verified in CWS tkr32.