[SOLVED] Who wants to fork gedit to fix 2 yr network share saving bug?

[mssever]

Here is the relevant part copied from comment 20:
The problem with gedit is the "save" routine. It relies on moving the file that is being edited while the filehandle is kept open. This works for most filesystems, but it fails on cifs and sshfs.

It seems to me that the proper solution is to fix the filesystem. Having special case behavior for different filesystems, or reducing the program to use the lowest common denominator, is only a band-aid that doesn't solve the problem (and can easily make matters worse in the long run). Filesystems should present a common interface. If what you quoted is correct, that's the real problem. (I haven't read the links you gave.)

The problem with forks boils down to this: you either split developer mindshare (which hurts everybody); or your fork suffers from a lack of mindshare. If you don't have adequate mindshare, you fall behind.

What about the following compromise: Make your own custom deb with a patch for the bug (as is common in debs). Every time a new release of Gedit comes down the pike, evaluate it and update your deb accordingly. Of course, you should send your patch upstream, but if it's the wrong solution (as it appears), don't expect it to be accepted.

[MountainX]

*Update*

**_EVEN_** with Gedit's default backup file behavior enabled,
I encounter no problems whatsoever when using sshfs like this:

 sshfs -o uid=$UID username@hostname:directory mountpoint

I have never tested it with sshfs because I've been told that sshfs isn't suitable for large files (videos, backups, virtual machine images, etc.).

I

[MountainX]

It seems to me that the proper solution is to fix the filesystem. Having special case behavior for different filesystems, or reducing the program to use the lowest common denominator, is only a band-aid that doesn't solve the problem (and can easily make matters worse in the long run). Filesystems should present a common interface. If what you quoted is correct, that's the real problem. (I haven't read the links you gave.)

The problem with forks boils down to this: you either split developer mindshare (which hurts everybody); or your fork suffers from a lack of mindshare. If you don't have adequate mindshare, you fall behind.

What about the following compromise: Make your own custom deb with a patch for the bug (as is common in debs). Every time a new release of Gedit comes down the pike, evaluate it and update your deb accordingly. Of course, you should send your patch upstream, but if it's the wrong solution (as it appears), don't expect it to be accepted.

Good suggestions. My opinion is the same as Peter's: renaming or moving an open file is a bad solution. Therefore, I do not agree that the focus should be placed on changing the filesystems (cifs, smbfs, etc.).

The whole reason gedit has been stuck with this bug for over two years is that each side points the finger at the other side. As long as that is going on nothing will get done. The file system people are not going to do any work to support a behavior they feel is incorrect (and that makes perfect sense to me).

The only way to move forward to is deal with this on the editor side.

[MountainX]

I'm going to copy from Peter's original comment here:
https://bugs.launchpad.net/gedit/+bug/34813/comments/20

He says:

Ok, this is the problem:

Gedit opens a file, moves the original file to a backup file while keeping the file open, and finally deletes the backup file if you choose not to keep backups.
The rename method sets errno = ETXTBSY, so moving the original file fails.

I don't think moving/deleting open files on purpose is a good idea, although it works for most linux file systems. But its definitely a bad idea for network file systems like sshfs and cifs, which of course fails.

This explains why disabling the backup preference in gedit doesn't solve the issue under cifs shares to Windows computers. If I understand Peter correctly, when the backup option is disabled, the attempt to move/rename the file is still made.

[MountainX]

I justed tested this with Gedit over sshfs on 7.10 Gutsy.

on a Graphically "mounted" sshfs via Nautilus "Places -> Connect to Server,"
I encountered no problems whatsoever.

I think the most of the people seeing the problem are using shares residing on Windows machines.

I saw the issue and resolved it by simply telling Gedit not to create backup files:

As your later post indicates, this seems to have nothing to do with the "backup" preference in gedit. I understand gedit still attempts to move the original file no matter how this option is set.

[frego]

I just did some testing myself. I'm mounting a cifs share from Gutsy on an XP box using fstab of:

//winbox/share /mnt/winbox cifs credentials=/home/myusername/.smbpasswd,noperm,nocase,file_mode=0777,dir_mode=0 777 0 0

and gedit will open and save to a file on that share, although periodically, it does give me a weird message:

"The file /mnt/winbox/test.txt has been modified since reading it.
If you save it, all the external changes could be lost. Save it anyway?"

I'm allowed to choose "save anyways" or "don't save". If I choose "Save anyways", it saves it. So the message is annoying but hardly anything worthy of forking. I also notice my ~ file is created ok too. Maybe your experience differs from mine because you aren't mounting the same way, or perhaps its a difference between an actual windows box and a samba share. Either way, I don't see it being a gedit issue. Or am I missing something?

[MountainX]

Or am I missing something?

Just wait 'til you upgrade to Hardy. Then it will be completely broken.

[frego]

I just did my above testing on a Hardy machine and gedit still works! I do still get the nag message though.

I did have some trouble getting my cifs share to mount. For anyone else, I had to install smbfs to be able to mount as shown in my previous thread. Can you replicate this problem on a windows share or are your files you are trying to edit on a samba share?

[MountainX]

I just did my above testing on a Hardy machine and gedit still works! I do still get the nag message though.

Wow. I will have to keep trying. I could get it to work under Gutsy but not under Hardy now. I understand that in Hardy smbfs is just a wrapper for cifs. Maybe you installed something that is in addition to the Hardy packages?

I did have some trouble getting my cifs share to mount. For anyone else, I had to install smbfs to be able to mount as shown in my previous thread. Can you replicate this problem on a windows share or are your files you are trying to edit on a samba share?

By "samba share" do you mean smbfs on Linux servers? And by "windows share" do you mean samba client connected to Windows machines? I'm still trying to get all the terminology straight.

[frego]

By "samba share" do you mean smbfs on Linux servers?

YES

And by "windows share" do you mean samba client connected to Windows machines?

YES, I meant my ubuntu machine mounting a native (true) windows share, XP SP2 through mount -t cifs (see my fstab from prior post for exact syntax. NOTE: specific permission for files and directories that was needed.)

Maybe you installed something that is in addition to the Hardy packages?

YES
What I installed on my Hardy machine that finally allowed me to mount was to go into Synaptic and add the program whose name is:
smbfs

It wasn't installed by default even though samba client is.