Bug 479199 - posix apis unreliable on files mounted over gvfs, e.g. truncate, open, causes OpenOffice.org to fail to save.
posix apis unreliable on files mounted over gvfs, e.g. truncate, open, causes...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gvfs (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
:
: 479658 (view as bug list)
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2009-01-07 17:08 EST by William Lovaton
Modified: 2015-03-03 17:33 EST (History)
11 users (show)

See Also:
Fixed In Version: 1.0.3-6.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-03 10:24:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Message 1 and 2 (10.59 KB, image/png)
2009-01-07 17:09 EST, William Lovaton
no flags Details
Message 3 (8.58 KB, image/png)
2009-01-07 17:17 EST, William Lovaton
no flags Details
standalone test-case (865 bytes, text/plain)
2009-01-15 04:51 EST, Caolan McNamara
no flags Details
gvfs-fuse-truncate-immediately.patch (913 bytes, patch)
2009-02-26 08:55 EST, Hans Petter Jansson
no flags Details | Diff

  None (edit)
Description William Lovaton 2009-01-07 17:08:49 EST
Description of problem:
OpenOffice Calc shows three error messages when trying to save an .xls file on a remote folder accessed via gvfs.  I tried both smb and ssh mounts and they failed in the same manner.

I'll attach screenshots of the error messages in a followup.  I didn't tried with other file formats except for .xls but I guess this doesn't have anything to do with the error.

I'm transcribing the errors for searchability:

Message 1 and 2 (they are the same):
Error saving the document test:
General input/output error while accesing /home/william/.gvfs/sftp for nalwalovaton on 192.1.2.69/home/nalwalovaton/test.xls

Message 3:
Error saving the document test:
Write Error.
The file could not be written.

Version-Release number of selected component (if applicable):
openoffice.org-brand-3.0.0-9.10.fc10.i386
openoffice.org-base-core-3.0.0-9.10.fc10.i386
openoffice.org-writer-3.0.0-9.10.fc10.i386
openoffice.org-draw-3.0.0-9.10.fc10.i386
openoffice.org-ure-3.0.0-9.10.fc10.i386
openoffice.org-core-3.0.0-9.10.fc10.i386
openoffice.org-langpack-en-3.0.0-9.10.fc10.i386
openoffice.org-graphicfilter-3.0.0-9.10.fc10.i386
openoffice.org-base-3.0.0-9.10.fc10.i386
openoffice.org-writer2xhtml-0.5.0.2-2.fc10.i386
openoffice.org-xsltfilter-3.0.0-9.10.fc10.i386
openoffice.org-presenter-screen-3.0.0-9.10.fc10.i386
openoffice.org-pyuno-3.0.0-9.10.fc10.i386
openoffice.org-calc-3.0.0-9.10.fc10.i386
openoffice.org-draw-core-3.0.0-9.10.fc10.i386
openoffice.org-report-builder-3.0.0-9.10.fc10.i386
openoffice.org-javafilter-3.0.0-9.10.fc10.i386
openoffice.org-langpack-es-3.0.0-9.10.fc10.i386
openoffice.org-calc-core-3.0.0-9.10.fc10.i386
openoffice.org-impress-3.0.0-9.10.fc10.i386
openoffice.org-math-3.0.0-9.10.fc10.i386
openoffice.org-pdfimport-3.0.0-9.10.fc10.i386
openoffice.org-extendedPDF-1.4-4.fc9.noarch
openoffice.org-math-core-3.0.0-9.10.fc10.i386
openoffice.org-emailmerge-3.0.0-9.10.fc10.i386
openoffice.org-impress-core-3.0.0-9.10.fc10.i386
openoffice.org-writer-core-3.0.0-9.10.fc10.i386
openoffice.org-presentation-minimizer-3.0.0-9.10.fc10.i386


How reproducible:
Always if you open the file double clicking from Nautilus.  If I open the file directly from OOo (through the file dialog) it works fine...  Bummer!.

Steps to Reproduce:
1. Mount a remote volume using nautilus (eg. ssh:// or smb://)
2. Browse the volume with Nautilus and double click an .xls file
3. Do some modifications and try saving it clicking the save button.
4. Kaput: three error messages show up one after another.
  
Actual results:
The file doesn't get saved

Expected results:
Modification gets saved into the file on the remote location

Additional info:
I recently reinstalled my office computer from Fedora 8 to Fedora 10.  Editing files with OpenOffice on a remote location is a very common use case for me and it was working fine on Fedora 8 (Never tried Fedora 9 due to a bug with gvfs mounting smb volumes).
Comment 1 William Lovaton 2009-01-07 17:09:56 EST
Created attachment 328421 [details]
Message 1 and 2
Comment 2 William Lovaton 2009-01-07 17:17:55 EST
Created attachment 328423 [details]
Message 3

A wild guess would be credential problems.  In Fedora 8 I remember that OpenOffice would forget about the credentials if I left the file opened for a very long time.  It would ask me again the user name and password and it would save the file without any problem.
Comment 3 David Tardon 2009-01-08 09:33:07 EST
Reproduced.

Moreover, when I try it with ODS instead of XLS, there are three (not two) different cases:

1. Opening a remote file directly from OOo.
In this case I get Filter Selection dialog and have to select type of the file; the file opens without problems after that and it's possible to save it again.

2. Opening a file by clicking on it's icon in Nautilus when OOo is running.
The file is opened normally, but when I modify it and try to save it, I get yet another error message:

"Error saving the document xyz:
Object not accessible.
The object cannot be accessed
due to insufficient user rights."

On second try, the file is saved with no message at all...

3. Opening a file by clicking on it's icon in Nautilus when OOo is _not_ running.
The file is opened read-only.
Comment 4 Caolan McNamara 2009-01-08 09:40:49 EST
caolanm->dtardon: workspace.cmcfixes50.patch adds an alternative implementation for getting the length of a file (seeing as the gio file-size attribute is totally useless) which *may* make a difference to some of this.
Comment 5 Caolan McNamara 2009-01-12 06:51:06 EST
*** Bug 479658 has been marked as a duplicate of this bug. ***
Comment 6 Caolan McNamara 2009-01-13 07:17:50 EST
caolanm->dtardon: I've built 3.0.1-15.1 as an F-10 update, can you check when that build becomes available if the problem persists.
Comment 7 David Tardon 2009-01-14 10:12:19 EST
dtardon->caolan:
It's not much better, actually... There are three distinguishable cases, again:

1. Opening a remote file directly from OOo.
Works all right, read-write and so on.

2. Opening a file by clicking on it's icon in Nautilus when OOo is _not_
running.
The file is opened read-only.

3. Opening a file by clicking on it's icon in Nautilus when OOo is running.
The file is sometimes opened read-only, sometimes read-write; it looks like
the opening state changes determinstically.
If it's been opened read-write and I try to change it and
save it, it shows:

"Error saving the document xyz:
Object not accessible.
The object cannot be accessed
due to insufficient user rights."

On second try to save it shows twice

"Error saving the document test:
General input/output error while accesing /home/william/.gvfs/sftp for
nalwalovaton on 192.1.2.69/home/nalwalovaton/test.xls"

(the actual content is different, but's the same message) and then

"Error saving the document x:
General Error.
General input/output error."
Comment 8 Caolan McNamara 2009-01-14 12:06:06 EST
The issue possibly pivots around what url is given to OOo. If started from nautilus OOo actually gets a url like 
"soffice /home/caolan/.gvfs/path/to/file.xls". There was some sort of "give me the real url" flag in .desktop files at one stage, but it went away in favour of a gio api to "map this ~/.gvfs patch back to sftp://whatever" routine, but where and how using something like that could be wedged into OOo escapes me entirely.

So its possible that this doesn't actually go near the gio implementation in OOo which only kicks in if given a url which can't be handled by the built-in protocol handlers. So this error might not be coming from the gio handler, but actually from the normal file:// handler, and that we *have* a gio backend may be a red herring. I'll take a look at it maybe tomorrow.
Comment 9 Caolan McNamara 2009-01-15 04:41:52 EST
So, the OOo gio backend isn't actually in use, its just the normal file-io in action, so capturable with strace. e.g. see this whacked out stuff.

[pid 24648] open("/home/caolan/.gvfs/sftp for caolan on nom/home/caolan/Documents/test.txt", O_RDWR|O_LARGEFILE) = 66
[pid 24648] ftruncate64(66, 0)          = 0
[pid 24648] close(66)                   = 0
...
[pid 24648] open("/home/caolan/.gvfs/sftp for caolan on nom/home/caolan/Documents/test.txt", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
[pid 24648] stat64("/home/caolan/.gvfs/sftp for caolan on nom/home/caolan/Documents/test.txt", {st_mode=S_IFREG|0600, st_size=52, ...}) = 0
[pid 24648] open("/home/caolan/.gvfs/sftp for caolan on nom/home/caolan/Documents/test.txt", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)

Gibberish, i.e. on saving 
"open the original"
"truncate it to 0"
"close it"
"reopen it, the file exists", which is ok
"stat it", which claims that it has *not been truncated* !
"try and open it, and the file doesn't exist", what... the... hell ?

vs on a local file-system where the right things happen

[pid 24756] open("/tmp/test.txt", O_RDWR|O_LARGEFILE) = 63
[pid 24756] ftruncate64(63, 0)          = 0
[pid 24756] close(63)   
...
[pid 24756] open("/tmp/test.txt", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
[pid 24756] stat64("/tmp/test.txt", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
[pid 24756] open("/tmp/test.txt", O_RDWR|O_LARGEFILE) = 63
Comment 10 Caolan McNamara 2009-01-15 04:51:08 EST
Created attachment 329075 [details]
standalone test-case
Comment 11 Caolan McNamara 2009-01-15 04:53:10 EST
gcc testme.c
cd /tmp
echo test > test.txt
~/a.out 
size is 0

(all ok)

cd ~/.gvfs/sftp for somewhere...
echo test > test.txt
~/a.out
size is 5
truncate claimed to work, but file size is still 5
can't open test.txt
: No such file or directory
Comment 12 Caolan McNamara 2009-01-15 05:10:50 EST
So the above standalone test-case shows weird and wrong results on truncating a file, calling opendir on the parent dir of that file, and then re-opening the file for writing
Comment 13 William Lovaton 2009-01-19 15:33:49 EST
Ok, the only workaround that seems to work is using "Save As..." instead of "Save".  I hope this helps for those of you suffering this bug.
Comment 14 pcjlinux 2009-01-24 17:05:11 EST
In case it helps, I don't have this bug using Open Office 2.4 with Ubuntu 8.10. I do have the bug with Open Office 2.4 and 3.0 in Fedora 10. What's the likelihood and timing of a potential fix with Fedora 10? ...
Comment 15 Caolan McNamara 2009-01-24 17:49:18 EST
The same problem was reproduced on latest Ubuntu, this is not OOo or Fedora specific
Comment 16 pcjlinux 2009-01-25 09:44:46 EST
Interesting. I don't have the problem on Ubuntu 8.10 with Open Office 2.4: I use Samba to access a public folder shared on my home LAN by a pc running Windows Vista. From Ubuntu, I can use Places > Network to navigate to the windows folder, click on an .xls file and open it in OO Calc 2.4 In OO Calc 2.4 I can then make a change and save the .xls file to the windows folder, without any error. If I try to perform the same sequence of operations in OO Calc 2.4 or 3.0 in Fedora 10, I get the gvfs error that prevents the save from completing successfully. The gvfs error does not occur in Fedora if I navigate to and open the file from within Calc, or if I "save as" from Calc (even if I "save as" back to the same file name).

So far as I know, I'm using a similar Samba configuration in both Ubuntu and Fedora... though I had to specify several more things to make the configuration work in Fedora...

Here's how I configure Samba in Ubuntu 8.10:

applications > add/remove  samba
in samba, add a share for /home/pcj/Public

sudo apt-get install winbind

edit /etc/nsswitch.conf and add 'wins' so that the hosts line looks something like this (order matters)

	hosts: files mdns4_minimal [NOTFOUND=return] dns wins mdns4

edit /etc/samba/smb.conf, to say:

	name resolve order = lmhosts wins bcast host

by default smb.conf should say:

	workgroup = WORKGROUP

I haven't tried OO 3.0 in Ubuntu, since I get the gvfs error in Fedora with both OO 2.4 and OO 3.0.
Comment 17 Caolan McNamara 2009-01-25 10:02:23 EST
Try the test-case of #10. (http://lists.go-oo.org/pipermail/dev-go-oo.org/2009-January/001050.html is the report from the Ubuntu OOo maintainer that the test-case fails on Ubuntu)

*Within* the gtk file picker various urls are returned and used, and so the gio apis are getting used directly by OOo as we can key off that to detect that it isn't a protocol that OOo handles internally. Launched from nautilus on the other hand a file path is given, so the gio apis aren't used by OOo, just the posix apis, which leads to the situation of attachment #10 [details]
Comment 18 pcjlinux 2009-01-25 11:12:24 EST
The Ubuntu maintainer's post at http://lists.go-oo.org/pipermail/dev-go-oo.org/2009-January/001050.html does not say how the bug was "confirmed to exist" in Ubuntu, so I cannot repeat his/her test... 

I can only say the bug does not happen for me in Ubuntu, when I perform the actions described above-- doubleclicking to navigate to the file and doubleclick to open it in Calc, then making changes and saving from Calc.

I've compiled and run the test program in comment #10 above, in both Ubuntu and Fedora ... in both cases it appears to run ok, if I understand the intent of the test: given a small text.txt file, it reduces it to size 0, and reports "size is 0". (?)
Comment 19 Chris Cheney 2009-01-25 13:38:46 EST
I am the Ubuntu maintainer of OOo. The way I reproduced this issue was to take Caolan's test program and run it on my local filesystem and on a gvfs mounted sftp filesystem. The sftp one gave this output:

ccheney@laptop-c2d:~/.gvfs/sftp on 10.0.0.1/home/ccheney$ ~/testme 
size is 5
truncate claimed to work, but file size is still 5
Comment 20 Chris Cheney 2009-01-25 13:53:52 EST
There are other issues with gvfs fuse filesystem support that probably aren't hurting anything currently but do function differently than a regular filesystem. For example with a regular samba mount you can set times on files eg (touch -d) but with gvfs it reports:

touch: setting times of `foo': Operation not supported
Comment 21 pcjlinux 2009-01-25 16:07:04 EST
Thanks for the clarification of how the issue was reproduced in Ubuntu... I am not using sftp, just smb... I guess for me, the analogous command would be(?):

   ~/.gvfs/'public on quark'/Documents$ ~/testme

when I try this command, I get the following error, when running on both Ubuntu and Fedora:

bash: /home/pcj/.gvfs/'public on quark'/Documents$: no such file or directory

even though the command:

   ls .gvfs/'public on quark'/Documents 

gives a list of all files in the shared Documents folder, including test.txt.

Perhaps I'm doing the test wrong -- I'm just a newbie to linux...yet again, I'm seeing different behavior for a test that corresponds to the original bug that was reported, i.e. saving a file on a shared directory from Calc behaves differently in Ubuntu and Fedora, if the file was originally opened by double-clicking...in Ubuntu the file is saved without an error, apparently, while in Fedora the gvfs error is reported, and prevents saving the file.
Comment 22 pcjlinux 2009-01-25 16:15:13 EST
actually, the error when reported by bash omits the quotes around 'public on quark':

  bash: /home/pcj/.gvfs/public on quark/Documents$: no such file or directory

don't know if this is important or not.. the quotes were used in the command:

  ~/.gvfs/'public on quark'/Documents$ ~/testme
Comment 23 Hans Petter Jansson 2009-02-26 08:55:57 EST
Created attachment 333326 [details]
gvfs-fuse-truncate-immediately.patch

Potential fix.
Comment 24 Hans Petter Jansson 2009-02-26 09:21:19 EST
Could you see if the patch I posted has any bearing on the problem?
Comment 25 Alexander Larsson 2009-02-26 09:44:24 EST
Verified that the patch fixes the testcase at least.
Comment 26 Caolan McNamara 2009-02-26 09:51:29 EST
If the testcases works then OOo will work, it should be honestly representative.
Comment 27 Hans Petter Jansson 2009-02-26 10:00:46 EST
Committed patch upstream to trunk and 2-24 branches.
Comment 28 Tomáš Bžatek 2009-03-02 09:37:30 EST
(In reply to comment #20)
> There are other issues with gvfs fuse filesystem support that probably aren't
> hurting anything currently but do function differently than a regular
> filesystem. For example with a regular samba mount you can set times on files
> eg (touch -d) but with gvfs it reports:
> 
> touch: setting times of `foo': Operation not supported

We only added support for setting timestamps on smb in gvfs-1.1.1. I guess many other backends don't support setting timestamps either.

Some people also reported it still fails on smb but I still haven't received proper reproducer and it's working fine in our lab.
Comment 29 Fedora Update System 2009-03-02 09:59:08 EST
gvfs-1.0.3-6.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gvfs-1.0.3-6.fc10
Comment 30 Chris Cheney 2009-03-02 10:38:16 EST
(In reply to comment #28)
> (In reply to comment #20)
> > There are other issues with gvfs fuse filesystem support that probably aren't
> > hurting anything currently but do function differently than a regular
> > filesystem. For example with a regular samba mount you can set times on files
> > eg (touch -d) but with gvfs it reports:
> > 
> > touch: setting times of `foo': Operation not supported
> 
> We only added support for setting timestamps on smb in gvfs-1.1.1. I guess many
> other backends don't support setting timestamps either.
> 
> Some people also reported it still fails on smb but I still haven't received
> proper reproducer and it's working fine in our lab.

Is there kind of support needed on the Samba side for this to work? I have gvfs 1.1.6 on Ubuntu Jaunty (9.04 alpha 5) and it still says:

"touch: setting times of `blah': Operation not supported"

Also do you know if there is there an upstream bug I can take this discussion to?

Thanks,

Chris
Comment 31 Tomáš Bžatek 2009-03-02 12:03:23 EST
New rawhide packages are also available now: http://koji.fedoraproject.org/koji/buildinfo?buildID=92209

Please test it with OpenOffice and let us know how is it going.
Comment 32 Chris Cheney 2009-03-03 01:40:34 EST
(In reply to comment #23)
> Created an attachment (id=333326) [details]
> gvfs-fuse-truncate-immediately.patch
> 
> Potential fix.

I'm not sure if this is the same issue I am seeing with gvfs 1.1.7, but for me on Ubuntu OOo fails to save properly the first attempt but then saves on the second attempt. http://bugzilla.gnome.org/show_bug.cgi?id=573837 documents my error with a strace log. It appears if I am reading the log correctly it is caused by gvfs-fuse claiming to not support ftruncate?

Chris
Comment 33 Chris Cheney 2009-03-03 01:41:27 EST
(In reply to comment #23)
> Created an attachment (id=333326) [details]
> gvfs-fuse-truncate-immediately.patch
> 
> Potential fix.

I forgot to ask in the previous message, this patch did make it into gvfs 1.1.7, correct?
Comment 34 Fedora Update System 2009-03-03 10:24:22 EST
gvfs-1.0.3-6.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 35 Chris Cheney 2009-03-03 23:29:40 EST
I think in the case where you see:

"Error saving the document xyz:
Object not accessible.
The object cannot be accessed
due to insufficient user rights."

This is due to not being able to ftruncate a lock file to the size of the lock file (eg a NOP). This is because gvfs fuse currently only works for size == 0 if it is any other size including the same size as the file currently is it returns not supported. I wasn't sure how to fix the gvfs code to just return on trying to truncate to current file size so I hacked the OOo open create code to truncate to 0 if the file was opened in create mode which got rid of the error. So I think the proper fix for this would be to have gvfs check to see if f/truncate is called on a file that is already the right size and just return without error.
Comment 36 Chris Cheney 2009-03-04 14:55:00 EST
Alex Larsson fixed the problem I mentioned in #35 this morning.

http://svn.gnome.org/viewvc/gvfs?view=revision&revision=2286
Comment 37 Lorenzo Scano 2009-03-05 03:56:51 EST
Hello,
I posted bug 479658 (https://bugzilla.redhat.com/show_bug.cgi?id=479658) that was marked as a duplicate of this one. Upgrading to gvfs-1.0.3-6.fc10 didn't fix the problem completely; saving a file is now always successful but it is still opened read-only the first time and the lock is left in place when it is closed.
Please let me know if I can provide you with more infos.
Thank you a lot.

Note You need to log in before you can comment on or make changes to this bug.