GNOME Bugzilla – Bug 601274
Saves remote file locally
Last modified: 2009-11-10 18:05:01 UTC
I open file atmgrasp:/home/rick/pub/time.gnumeric over ssh (via nautilus) edit it, save it. Everything looks normal. But the file is not saved over the ssh share, rather it is saved on localhost as file /home/rick/pub/time.gnumeric It took me a while to sort out what was going on. Other programs do not behave this way, they read and write files across the share normally. If I open Gnumeric remotely from a command shell on the remote machine, everything functions as expected. This behavior began with install of Ubuntu 9.10, Gnumeric version is 1.9.9 It is new behavior, I have been accessing my timesheet on the portal from work and home this way for several months.
I am unable to reproduce. What do you see as "Location" in the File-> Properties menu?
The location in the file browser is sftp://rick@atmgrasp/home/rick/pub The location in the the File:properties menu is /home/rick/ Apologies, I made a significant mistake in the bug report, the file isn't saved in /home/rick/pub, but rather /home/rick, or ~ the default As a test, I created an empty document sftp://rick@atmgrasp/home/rick/pub/test.txt, opened it with gedit, saved it back and opened it again, no problem. Opened it with gvim, changed it, no problem. The original permissions on the gnumeric file were -rwx------, I changed this to -rw-rw-rw, no change in behavior. The test.txt file was created with -rwx------ (the x is annoying, but it doesn't matter) The remote is Fedora, and has not changed, both locals (home and work) are Ubuntu 9.10, which is a change. File server: Linux atmgrasp 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 16:52:18 EST 2008 x86_64 x86_64 x86_64 GNU/Linux work workstation: Linux euclid 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux Home workstation will be pretty much the same.
> The location in the the File:properties menu is /home/rick/ Then some program is copying the file before starting Gnumeric. From a shell, you should be able to say gnumeric sftp://rick@atmgrasp/home/rick/pub/time.gnumeric If this works, then Gnumeric is fine and your problem is elsewhere. Try starting Gnumeric in your regular way and type "ps -ef | grep gnumeric" from the shell. If it does not work, then Gnumeric/Goffice/Libgsf has been compiled without vfs support.
Cool that you are right on this Morten. # gnumeric sftp://rick@atmgrasp/home/rick/pub/time.gnumeric exhibits the same behavior that opening it from nautilus does, it saves the file in my home. process listing shows the correct file: rick 3517 1 2 05:00 ? 00:00:00 gnumeric /home/rick/.gvfs/sftp for rick on atmgrasp/home/rick/pub/time.gnumeric Is there a simple way to test the lib for vfs support? /usr/lib/libgsf-1.so.114.0.15 I know there is a way to list the targets in the lib, Google isn't helping me.
Filed bug at Ubuntu... https://bugs.launchpad.net/ubuntu/+source/gnumeric/+bug/479407
If gnumeric loads the file when you do gnumeric sftp://rick@atmgrasp/home/rick/pub/time.gnumeric then goffice and libgsf are fine. I have no idea why this isn't working right for you. Any chance you could try the very latest from Debian? 1.9.15 (with corresponding goffice and possibly libgsf).
I can replicate this with latest libgsf from Debian and Gnumeric git using a regular ftp connection. Note a few things: If I save a file to the ftp share with a new name, it in fact ends up there. If I open the file from the file dialog or through nautilus it opens fine but subsequent saves, save into the home directory.
I guess updating won't cure it then. I can try it with other share types from the office tomorrow to see if I get the same behavior as Andreas. From home I can only connect through ssh.
One more observation: If I open a file from a remote share (this time I used sftp), and I select "save as" then the current directory is my home directory, not the remote share as I would have expected.
Some more info: I open a file from within Gnumeric from an sftp share, modify it and select save. In wb_view_save we call char const *uri = go_doc_get_uri (GO_DOC (wb)); the returned value is: 1098 char const *uri = go_doc_get_uri (GO_DOC (wb)); (gdb) n 1099 wb_view_save_to_uri (wbv, fs, uri, io_context); (gdb) p uri $2 = 0x85650c0 "file:///home/aguelzow/git/gnumeric/Book1.gnumeric" and we end up saving to that location. So the question becomes: Why does goffice give us that (incorrect) uri?
Hmm, the GODoc definitely things we are looking at a local file: (gdb) p doc $4 = (const GODoc *) 0x8514ed0 (gdb) p *doc $5 = {base = {g_type_instance = {g_class = 0x82acb80}, ref_count = 2, qdata = 0x81469d0}, uri = 0x85c90c8 "file:///home/aguelzow/git/gnumeric/Book1.gnumeric", meta_data = 0x8525170, modified = 1, pristine = 0, images = 0x0, imagebuf = 0x0} (gdb)
We are getting the wrong input name from gsf. The following is in wb_view_new_from_input: 1171 if (NULL != (input_name = gsf_input_name (input))) { (gdb) 1172 char *uri = go_shell_arg_to_uri (input_name); (gdb) p input_name $1 = 0x80f2668 "Book1.gnumeric" (gdb) n 1173 go_doc_set_uri (GO_DOC (new_wb), uri); (gdb) p uri $2 = 0x85b7518 "file:///home/aguelzow/git/gnumeric/Book1.gnumeric" (gdb) Clearly we are telling our document the wrong uri after loading it.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Cool, thanks Morton. FOSS rocks!