it looks like with samba our check on the file mtime gets screwed :(

can you run gedit, save the file, then just before saving again, run a terminal and run "strace -p `pidog gedit` &> /tmp/strace-gedit.txt", save the file so that the error pops up, then go to the terminal and ctrl+C strace and attach the strace-gedit.txt log?

as discussed on IRC the issue comes from gedit/gedit-document-saver.c save_existing_local_file(): rename (saver->priv->local_path, backup_filename) complains about 'Text file busy'. Using a rename from a simple program works fine.  Changing the goto out for goto fallback_strategy workarounds the issue

I too get this problem on FC5.  I can save a file to a CIFS share, but not overwrite it once it's saved, but this behaviour only applies to gedit.

Also observing this behaviour on FreeBSD 6.1-RC1. Reverting to gedit 2.12 resolves the issue. Have tried make deinstall && make clean && make install, post doing a portupgrade, and still seeing the problem. Problem does not manifest with Bluefish (gtk-based IDE) or with vim, so it's definitely not a permissions issue on the samba share (also ruled out by use of gedit 2.12) or a wider issue with gnome or FreeBSD.

The problem seems to be that you can't rename an open file on a CIFS mounted directory. The workaround for this problem is to close the file descriptors before rename.  Here's a diff for this problem against gedit-document-saver.c from the 2.14.4 source. It's not the ideal solution but I thought it better to leave a complete solution to someone that's done C coding more recent than 6 years.

613a614,619
>               /* close the file so we can rename it */
>               if (close (saver->priv->fd) != 0)
>               {
>                       g_warning("couldn't close");
>               }
>
618d623
<
632a638,643
>               /* close tmpfd so we can rename it */
>               if (close (tmpfd) != 0)
>               {
>                       g_warning("could not close tmpfd");
>               }
>
658,659c669,670
<               if (fstat (tmpfd, &new_statbuf) != 0)
<               {
---
>               if (stat (saver->priv->local_path, &new_statbuf) != 0)
>               {
684d694
<

Oh, and I wasn't real sure about that last fstat so I changed it to stat the local path on the saver instead of fstat(tmpfd). I wasn't really sure what this was doing so be warned.

Ok, so I am a bit esitant here: on cifs/smb you can't rename an open file, but closing the file before renaming opens up a race (keeping the file open prevents it from being removed and/or replaced with e.g. a symlink). Is this a valid concern? Opinions?

right now I am leaning to change the goto, and just fallback to the other saving strategy if the rename fails?

I still get an error if i change the goto in the original->backup rename to goto the fallback_strategy. I have tracked down where it's failing though in the fallback_strategy though.

> I have tracked down where it's failing though in the fallback_strategy though

Can you share your findings? Or is that a typo and you meant "I haven't..." :)

Sorry, it's a typo. I _haven't_ tracked it down.

I can confirm that this problem exists with CIFS mounted shares and also appears to occur with SSHFS mounted shares (Ubuntu bug #36091).

I can confirm this bug. I've had the same issue with FC5, and Ubuntu Edgy. GEdit can save a new file to a mounted CIFS share, but not write to an existing file.
In both my cases, the server in question is a Windows 2003 Small Business Server, rather than SAMBA.
GEdit in FC4 and earlier seemed to work fine.

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.

comment on the ubuntu bug:

"It's NOT a Gedit bug. It's a Samba (cifs-protocol) bug. The same result using Geany, Vim and Eclipse working with files over CIFS (Windows 2003 Server). All of them applications with file-changes detection.

The issue is reported in several forums and lists:
http://www.nabble.com/multiple-problems-moving-up-from-smbfs-to-cifs-t3884792.html
https://bugzilla.samba.org/show_bug.cgi?id=3551
https://bugzilla.samba.org/show_bug.cgi?id=4076

For people working in a mixed net (linux & windows machines) over a Windows 2003 file-server it's a BIG issue. Very very annoying. I work as app/web developer using Eclipse, everytime I save a file I have an alert when I write something "The file has been changed on the filsesystem, do you want to overwrite the changes?", then I choose "Yes/No", then another alert "The file has been changed on the filesystem. do you want to load the changes?". If reload latest changes (after save) will be lost.

Everytime you save, everytime you see the alerts (even if you only change to another application and back after save). Think about it working in a project, saving and testing every code change.

Severe impact on professionals/developers working with Ubuntu over Smb/Cifs file server."

As far as I know, Samba isn't used to mount CIFS shares?

However, it is indeed very annoying.  I too work as a web developer, and it makes linux look really stupid to my boss when the default and best text editor can't edit files on the company network. Even worse, that the bug has been known about for well over a year and isn't seen as worth fixing because not enough people have come up against it.

I confirm this bug on Ubuntu Feisty gedit (and eclipse), but not with vi and nano.
The file server is Debian Sarge.

Hello,

We can confirm (and also have a customer that has confirmed) that the problem no longer occurs when using a package built with the patch in comment #5.

Also in testing we have conducted in handling the case reported by our customer, we found that this problem only occurs with Windows acting as the CIFS server, not with Samba as the CIFS server.

Perhaps the Gedit developers could review the patch in comment 5 and make a decision whether to use it?  Or if the method used in the patch is not considered favorable, perhaps do something else more palatable?

We want to provide a supported solution to our customer, but our process requires a patch be accepted/committed upstream before we can add the patch to our package builds -- even though we have seen the patch solves the problem.

Thanks,
Vince

> We can confirm (and also have a customer that has confirmed) that the problem
> no longer occurs when using a package built with the patch in comment #5.

I also suggested such a solution in the ubuntu bug tracker, people don't like the idea of that race condition.

what about this failsafe routines:

(a) if backup enabled:
- copy, not move the original file to a backup file
- reset file pointer, overwrite the original file in-place

(b) if backup disabled:
- reset file pointer, overwrite the original file in-place

or just tell the user that gedit is not able to backup the file and proceed with method (b) anyways if the user agrees

Is that still an issue with Gedit 2.22/gvfs ? The samba.org bug reports have been partly fixed a while ago and the patches are already include in kernel 2.6.24 (which everyone seems to be using these days).

Some discussion is going on here:
http://ubuntuforums.org/showthread.php?t=738168

BTW, the issue is even worse in Ubuntu Hardy beta with the new gvfs and gedit 2.22.0. I had a work-around in earlier versions (use smbfs instead of cifs) but that doesn't help now.

this bug is horrible, i had to switch to nfs which i dont like as much

i had recompiled a old version of gedit without any checking on save of changing on disk but it will not work in hardy, and i dont want to recompile when i like the new matching bracket feature

This no longer seems to be a problem with gedit/gvfs-smb in Ibex.  Can we find the patch that fixed it to backport to Hardy for long-term-support?

I still have the issue with gedit 2.24.2 under Ubuntu 8.10.  The problem affects only SMB shares that are provided by Windows servers.  I could not reproduce the problem with SFTP or SMB mounts that were provided by Linux/Ubuntu servers.  However, the bug also affects Nautilus when I try to copy over an existing file on the Windows SMB share. 

I have this problem with files mounted in fstab using cifs (gedit 2.42.2 in 32-bit Ibex). The files are not on a Windows server but rather a Buffalo Linkstation network drive. I am able to save the file after agreeing to the alert, but I agree with Sebastien above that this is an extremely annoying issue (enough so that I won't continue to use Gedit if I can't resolve it).

Could anybody check if this problem persist with gedit 2.26.0 ?

If there's a 32-bit Ubuntu deb file available I'd be glad to test it out and report back.

Using gedit 2.26.1 (Ubuntu 9.04 "Jaunty"), the problem does not seem to occur for me anymore.  Seems to be fixed.

definately not fixed for gedit+cifs in gedit 2.26.1 (Ubuntu 9.04 "Jaunty")

The same problem exists for files on VirtualBox shared folders, using Windows as a host and Ubuntu 9.04 as the guest.  Windows doesn't allow renaming open files, so it's that restriction shining through.

It would at least be nice to change gedit so the rename isn't done if the "make backup file" option is off -- right now gedit does the rename and then unlinks the file.

Can be reproduced with Fedora 11 too:
https://bugzilla.redhat.com/show_bug.cgi?id=492615

Fedora 11 ships with gedit 2.26.2 so the problem persists with recent versions.

This problem still exist in Gedit 2.28.0 in Ubuntu 9.10. Backup files are disabled. Using cifs against a Windows server.

On the other hand the problem seems to have been fixed in Fedora 12:
https://bugzilla.redhat.com/show_bug.cgi?id=492615

The current Fedora 12 version is Gedit 2.28.3, initial version was Gedit 2.28.0. I don't see patches that seem related to this bug:
	$ rpm -qpl gedit-2.28.0-1.fc12.src.rpm 
	gedit-2.25.5-fix-python-path.patch
	gedit-2.28.0.tar.bz2
	gedit.spec
	print-to-file.patch
	$ 
	$ rpm -qpl gedit-2.28.3-1.fc12.src.rpm
	gedit-2.25.5-fix-python-path.patch
	gedit-2.28.3.tar.bz2
	gedit.spec
	print-to-file.patch
	$

I find this bug fixed in gedit-2.30, (whereas it was close to driving me crazy in 2.26) however one small issue remains. A file (in this case a script) that is marked executable (755) will lose the first exec permission and be saved as 655. This doesn't appear to happen in vim.

share in smb.conf:

[Datavault]
  allow hosts = 192.168.1.101 192.168.1.102
  browseable = no
  case sensitive = yes
  create mask = 0644
  path = /mnt/Datavault
  valid users = byteframe
  writable = yes

client fstab entry:

  //192.168.1.100/Datavault /mnt/Datavault cifs credentials=/etc/dvcred 0  0

Being mounted during boot/init by root, 'man mount.cifs' assures me the exec option is being applied, as it seems to be (can run scripts, etc).

I apologize in advance if I needed to open a seperate bug entry, but this one's title seemd vague enough. :)

I've retested this with gedit2.32, with the same information in my previous post, but the problem remains. I prefer to have files in my smb share created non-executable, and so I'm using 'create mask = 0664' in the share definition for this. 

Without 'create mask = 0664', files are created executable (744), and everything is otherwise normal. The permissions are not changed when I edit and save a file on a samba share using gedit.

With 'create mask = 0664' on, files are created non-executable (644), however editing files that have been marked executable (for one reason or another) using gedit will have those files saved with the first executable permission removed. A file marked 0755 would become 0655 after saving with gedit. This is not the case editing the file using vim.

Odd.

I had a quick peek at the gvfs backend for smb, and it seems it doesn't properly restore the file permissions of the file being replaced. I'm reassigning this to gvfs. I would be happy to provide a patch for the smb backend if I could get some pointers from gvfs devs as to what should be changed.

Thank you for looking into this. Just to reiterate, I'm using a smb share that was been mounted with fstab, not gvfs.

I'm sorry, I overlooked that. Now, I did some small tests on a CIFS share I have, and it seems I can't chmod anything (but it will not report this as an error). The problem then becomes that the file saving strategy that we use (which nowadays resides in gio) writes out a temporary file, renames that file and then relies on chmod to restore permissions. Normally, if the permissions could not be restored, it will go to a fallback strategy which truncates the file.

I can see one possible solution for this to be solved, which is not to have gio rely on the result of chmod to check wether or not the permissions were really changed. I'm reassigning to gio to see what they think.

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

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/46.