gedit should support writting on network shares

[Ian Dees]

I'm trying to use a Warty Warthog desktop to read and modify text files that
live on a remote BSD box running Apache 1.x with mod_dav 1.0.3. When I use File
>> Connect to Server... to access the DAV share, Nautilus mounts the remote
folder beautifully -- as read-only, however. Gedit shows the file as read-only,
and Nautilus reports that it can't determine the permission information for the
file. On the same Ubuntu desktop, I can apt-get install kate and read/write the
exact same file that Nautilus/gedit balked at. I can also read/write the same
file from a Mac OS X laptop. Therefore, I'm confident that things are somewhat
okay on the server end (mod_dav has sufficient permission to write the files, etc.).

I've looked at the Ubuntu wiki and Googled for this problem, and I haven't been
able to find any fixes. If there's some configuration setting I'm missing on my
desktop, I solemnly swear to write up a nice, easy-to-follow guide on the wiki
on how to enable this setting.

I can supply a URL via private e-mail for someone to test with (someone who's
willing to be fairly gentle to the test directory, that is).

Thanks,

Ian

http://bugzilla.gnome.org/show_bug.cgi?id=110191: http://bugzilla.gnome.org/show_bug.cgi?id=110191

[Sebastien Bacher (seb128)]

(In reply to comment #0)

> Gedit shows the file as read-only,

Could you provide details on this. Do you mean that you can't edit the open file ?

Is there server a secure one ?

> I can supply a URL via private e-mail for someone to test with (someone who's
> willing to be fairly gentle to the test directory, that is).

That could be useful, thanks :)

[Filip Palm (helmut) (bugzilla-helmut)]

(In reply to comment #0)
> I'm trying to use a Warty Warthog desktop to read and modify text files that
> live on a remote BSD box running Apache 1.x with mod_dav 1.0.3. When I use File
> >> Connect to Server... to access the DAV share, Nautilus mounts the remote
> folder beautifully -- as read-only, however. Gedit shows the file as read-only,
> and Nautilus reports that it can't determine the permission information for the
> file. On the same Ubuntu desktop, I can apt-get install kate and read/write the
> exact same file that Nautilus/gedit balked at. I can also read/write the same
> file from a Mac OS X laptop. Therefore, I'm confident that things are somewhat
> okay on the server end (mod_dav has sufficient permission to write the files,
etc.).
>
> I've looked at the Ubuntu wiki and Googled for this problem, and I haven't been
> able to find any fixes. If there's some configuration setting I'm missing on my
> desktop, I solemnly swear to write up a nice, easy-to-follow guide on the wiki
> on how to enable this setting.
>
> I can supply a URL via private e-mail for someone to test with (someone who's
> willing to be fairly gentle to the test directory, that is).
>
> Thanks,
>
> Ian

This is a known problem with gedit, it is not network transparant or what you
call it, you can only edit local files and not files on a remote location.

[Ian Dees (undees)]

Sebastien wrote:

> Could you provide details on this. Do you mean that you
> can't edit the open file ?

Correct. Nautilus shows the file with unknown permissions,
and gedit marks the file with an "RO" suffix (and won't allow
me to make any changes).

> Is there server a secure one ?

The server is just a mod_dav installation I enabled as
a demo. It's not over a secure https:// link, but there's
nothing valuable on it, so I don't mind sending the
address and access info to someone in private.

But from what Helmut is saying, it sounds like this
step might be unnecessary (see below). If you guys
think it will help, I can still send the address,
depending on the response to my comments below:

Helmut wrote:

> This is a known problem with gedit, it is not network
> transparant or what you call it

That's interesting. The GTK file chooser allows me to
navigate to a remote WebDAV share, so I thought this
access was something built into the desktop at a deeper
level than gedit (something like KDE's kioslaves).

Is there another user-level Ubuntu app where I can
test network transparency over WebDAV to see if the
problem is specific to gedit or is system-wide?

Anyway, thanks to both of you for the clarifications.

[Sebastien Bacher (seb128)]

> That's interesting. The GTK file chooser allows me to
> navigate to a remote WebDAV share, so I thought this
> access was something built into the desktop at a deeper
> level than gedit (something like KDE's kioslaves).

In fact gnomevfs handle the remote filesystems in a transparent way in GNOME.
But applications have to use it explicitly. The current situation is that most
of the GNOME apps are able to read a file on a network share but not to save it.
BTW Gedit 2.10 should allow to save on network shares.

> Is there another user-level Ubuntu app where I can
> test network transparency over WebDAV to see if the
> problem is specific to gedit or is system-wide?

I don't use WebDAV so I'm not sure (I can't think to one app that do this for
the moment) but I'll let you know if I get some informations on this.

BTW the server access is probably not required, thanks anyway :)

[Daniel Robitaille (robitaille)]

There is a upstream bug report on this problem. And it seems likely a solution
will make it into gnome 2.12:
http://bugzilla.gnome.org/show_bug.cgi?id=110191

[Sebastien Bacher (seb128)]

*** Bug 14158 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

*** Bug 26534 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

This is fixed with that upload:

gedit (2.13.0-0ubuntu1) dapper; urgency=low

  * New upstream release:
    - Reworked codebase based on the new_mdi cvs branch,
      among other things, it features:
    - improved tabbed widget, for instance tabs are reorderable
    - GtkUIManager is now used for menus and toolbar instead of
      libbonoboui
    - A side panel and a bottom panel have been added
    - A new gobject-based plugin system has been implemented
    - Plugins can now be written in Python
    - Reading and writing of files are now handled in an
      asynchronous way (so the user interface never blocks)
    - Local files are read using mmap (when possible)
    - Incremental search is supported (use Ctrl+K)
    - A lot of usability improvements with some new UI experiment
      are featured
    - Startup time and performaces have been improved
    - Remote file saving is supported (for a limited configurable
      set of VFS methods)
  * debian/control.in:
    - bumped Build-Deps on glib and gtk.
    - dropped Build-Dep on libeel, libbonoboui2-dev, liblpint-bonobo.
    - added Build-Deps on python-dev (>= 2.4), python-gtk2-dev (>= 2.7.1),
      python-gnome2-extras-dev (>= 2.11.4), liblaunchpad-integration-dev.
    - added Depends ${python:Depends} to gedit.
  * debian/rules:
    - build with --enable-python
    - call dh_python
  * debian/gedit.install:
    - removed debian/tmp/usr/lib/bonobo,
    - added debian/tmp/usr/lib/gedit-2/plugins/*.py*
  * debian/patches/01_lpint_bonobo_src.patch:
    - dropped.
  * debian/patches/01_lpi:
    - new patch for gedit LPI.
  * debian/patches/02_autoconf:
    - updated.

 -- Daniel Holbach <email address hidden> Mon, 12 Dec 2005 20:36:01 +0100