In old versions, One could open a file over an ssh connection with geany to do editing. Im not using a version of linux that has GTK anymore, so compiling older versions isnt going so well. And no, Im not planning on installing old as hell gtk to see if geany 0.21 will allow for editing files over the network. It used to work, and it works no more. The file editor pluma has no problem with this functionality, but pluma is a sucky editor/ compiler. The mechanism I use to connect to files, is thought the window manager caja, then to select geany when opening the file. Geany does in cfact open, but no file is present. Please advise, I will provide any log if it helps to fix this.
here is geany -v for starters: ``` $ geany -v
(process:20174): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Geany-INFO: Geany 1.26 (git >= c089861), C Geany-INFO: GTK 2.24.25, GLib 2.42.1 Geany-INFO: System data dir: /usr/local/share/geany Geany-INFO: User config dir: /home/e/.config/geany Geany-INFO: System plugin path: /usr/local/lib/geany Geany-INFO: Added filetype Graphviz (61). Geany-INFO: Added filetype CUDA (62). Geany-INFO: Added filetype JSON (63). Geany-INFO: Added filetype Cython (64). Geany-INFO: Added filetype Clojure (65). Geany-INFO: Added filetype Scala (66). Geany-INFO: Added filetype Genie (67). Geany-INFO: /home/e/Desktop/f.html : HTML (UTF-8) Geany-INFO: /home/e/Downloads/jcamp-1.0/uvvis_spectra/toluene.jdx : None (UTF-8) Geany-INFO: /home/e/Downloads/jcamp-1.0/jcamp.py : Python (UTF-8) Geany-INFO: Loaded /usr/local/share/geany/python.tags (Python), 5964 tag(s). Geany-INFO: /home/e/Downloads/jcamp-1.0/setup.py : Python (UTF-8) Geany-INFO: /home/e/Desktop/shit.py : Python (UTF-8) Geany-INFO: /home/e/public_html/index.html : HTML (UTF-8) Geany-INFO: /home/e/Desktop/HoursJ2015-F2016 : None (UTF-8) Geany-INFO: /home/e/Downloads/phpuri-master/README.md : Markdown (UTF-8) Geany-INFO: Bad color 'string_3' Geany-INFO: Bad color 'string_3' Geany-INFO: Bad color 'string_4' Geany-INFO: Bad color 'string_4' Geany-INFO: /home/e/Downloads/phpuri-master/composer.json : JSON (UTF-8) Geany-INFO: /home/e/Downloads/phpuri-master/phpuri.php : PHP (UTF-8) Geany-INFO: Loaded /usr/local/share/geany/php.tags (PHP), 4396 tag(s).
```
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921
Geany never edited files over the network and never has, so there is no need to check old versions. But Geany can edit files on remote systems if they are mounted on the local filesystem. Some file managers do that by default when you browse remote filesystems, and when they activate geany they pass the locally mounted file path to geany.
What has probably changed is that your new system hasn't been set up to mount the remote filesystem, or it doesn't silently mount the remote filesystem when you browse it with the file manager, or it unmounts it before geany opens the file. You might be able to tweak some settings on the system to fix this.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-189783657
Yes, this is the functionality I am referring to. I might agree, that perhaps the filemanager has something to do with it, but other programs work with the same functionality, so clearly thats not the case.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-189784559
Pluma is the MATE editor, it is heavily integrated with the MATE system, including Caja. That is fine for MATE systems, but Geany is portable to other systems, including Windows and OSX where such integration would not be available.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-189788376
@mf0hka Would you try different combinations of
use_atomic_file_saving use_gio_unsafe_file_saving
from Preferences->Various to see if it makes any change? These affect file opening too since https://github.com/geany/geany/pull/621
Having the first unselected and the second selected should be the most compatible option.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-191754663
@mf0hka Do you have gvfs-fuse installed and properly setup (e.g. with your user allowed to mount FUSE mounts)? It's the module that allows GVFS (the virtual file system used by GNOME, MATE and others) to mount remotes locally. When installed and setup properly, it should works out of the box without further configuration or anything.
The reason tools like Pluma work without it is that they use GVFS directly, where Geany generally uses plain C-library-level read/writes, which isn't aware of the remotes -- nor knows how to write to them -- without a local mount (FUSE).
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-191776885
Is this a bug in Geany or a mis-configured system?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-192857047
@kugel- AFAICT its a misconfigured system, or a file browser that doesn't mount the remote any more.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-192866393
Then this can be closed
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-192867838
I think so, thanks for pinging.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-192870487
Closed #921.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#event-579201077
The reason tools like Pluma work without it is that they use GVFS directly...
Couldn't Geany do that too, on Linux?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-192974573
@codebrainz when you provide the pull request for it :)
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193018289
@codebrainz we could, but that would mean using the GIO API only, never ever paths or anything like it. The whole mess about file saving so well documented by @elextr would be reduced to the `g_file_replace_contents()`, with its pros and cons.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193021102
@b4n we could always add *another* option :smile:
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193026552
@b4n that sounds like a good thing, no? We get a lot more bugs about network file support than about the internal atomic details of other file saving methods that are available in hidden preferences.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193066293
@codebrainz so you advocate supporting network file operations, something inherently unreliable, with a saving method that is inherently unsafe when a failure occurs?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193067435
@elextr I advocate using the recommended file IO methods of GLib/GIO.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193073166
Yes, unsafe, unreliable and unfixable.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193078055
Yes, unsafe, unreliable and unfixable.
[citation needed]
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193084192
Read the source, was checked by Dimitar or Jiri (I forget who, sorry guys) recently and the bug still exists.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193085969
@elextr what about actual bug reports, like:
https://sourceforge.net/p/geany/bugs/871/ https://sourceforge.net/p/geany/bugs/1043/ https://sourceforge.net/p/geany/bugs/1034/ https://sourceforge.net/p/geany/bugs/728/ https://sourceforge.net/p/geany/bugs/493/ https://sourceforge.net/p/geany/bugs/489/ https://sourceforge.net/p/geany/bugs/447/ https://sourceforge.net/p/geany/bugs/387/ https://sourceforge.net/p/geany/bugs/318/ https://github.com/geany/geany/issues/828/ https://github.com/geany/geany/issues/893/ https://github.com/geany/geany/issues/838/
Found on a quick skim of SF.NET/GH for "remote and "ftp".
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193089196
@codebrainz sure, but using a known buggy GIO to trade for a different set of complaints isn't sensible. We already have plenty of complaints from people who lose data when their sshfs connections fail, lets not add everybody who accesses any remote file system to that list.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193091066
but using a known buggy GIO
[citation needed]
We already have plenty of complaints from people who lose data when their sshfs connections fail
[citation needed]
lets not add everybody who accesses any remote file system to that list.
[citation needed]
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193092287
Well, doing remote access ourselves is an enhancement not a bug, and for sure a clear issue can be created for it if one doesn't already exist. Then issues of how it should be implemented can be discussed there with whoever is proposing to implement it.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193095702
but using a known buggy GIO
https://bugzilla.gnome.org/show_bug.cgi?id=602412 Added to @elextr's thesis for reference. This is the real annoyance here, because we *know* it fails miserably in that case.
However, I'm not really sure it's actually worse than plain write, as the only disadvantage over it would be speed on *some* scenarios. The `use_atomic_file_saving` (`g_file_set_contents()`) has other safety advantages, but is too problematic on losing permissions. So maybe it'd be good enough to only keep the default way, and really use it to it's full potential. Yet IIRC we had issues with this, and a comment in the code says:
It is best in most GVFS setups but don't seem to work correctly on some more complex setups (saving from some VM to their host, over some SMB shares, etc.)
So we'd still have to be careful.
But I generally agree with you that we'd be happier with a single saving method using GIO, which is supposed to handle all the boring details for us. Unfortunately, it's not as pretty as that…
However, maybe we could implement a halfway solution in the meantime, using the full GIO potential when using `g_file_replace_contents()` (the default), and fallback to failing on non-local mounts if another method is selected. I'm not quite sure of what code changes that would mean, but that might be possible and the least "dangerous" option (e.g. keep all the complexity we have for all weird cases, yet default to fully supporting GFVS).
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193205790
@codebrainz we could, but that would mean using the GIO API only, never ever paths or anything like it. The whole mess about file saving so well documented by @elextr would be reduced to the g_file_replace_contents(), with its pros and cons.
@b4n This is what we already do when use_gio_unsafe_file_saving=TRUE since https://github.com/geany/geany/pull/621 (well, for the edited files only, not for Geany config files etc. but there's no point using GIO for those) - this is why I asked what settings @mf0hka is using.
Now in my opinion the "unsafe" in the name is a bit unfortunate - it's much less unsafe than it may seem from the name and people might be disabling it because of it. The second unfortunate thing is there are 4 combinations of
use_atomic_file_saving use_gio_unsafe_file_saving
but just 3 different settings. Finally, the value isn't related to "saving" only any more - it determines the operations used both for opening and saving.
So it would be better to have a single entry in Various for this, something like "file_access_mode" with a dropdown containing 3 values - "GIO", "atomic", "POSIX", defaulting to "GIO" (I'd mention the unsafeness in the documentation with some more discussion but not directly in the mode name).
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193227774
Have just created #942 to continue this discussion somewhere specific rather than on a closed and only partly related issue.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193234190
@techee oh, right, forgot about that one. So now we should work without gvfs-fuse? That would mean we get an URI in `locale_filename`, which I'm not certain about. But indeed that would mean it might work right now, yet I would have to test in real situation to be sure myself.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193251461
So now we should work without gvfs-fuse?
Doesn't work here, giving an FTP file address at the command line.
It works if I mount the FTP server in Dolphin and then "Open With" Geany, but it only opens a local copy of the file (in `/home/me/.cache/kioexec/krun`), so you can't save (and if you try, it hangs the file manager for some reason).
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/921#issuecomment-193431195
github-comments@lists.geany.org