(fat32) Unexpected "file modified by another process" warning

[Rebecca Palmer]

Binary package hint: gedit

The warning message "The file (name) has been modified by another process since reading it. If you save it, all the external changes could be lost. Save anyway?" frequently appears when I try to save an existing file in gedit, when I haven't had the file open in anything else (though I do run a commercial on-access antivirus www.sophos.com). The file is saved normally if I select "save anyway".

The files I have seen it in are all on a FAT32 partition (where I also have the "can't back up" bug https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/69184), but unlike that bug, its occurrence is not limited to the first save of a session, but seems to be random. Both bugs can appear in the same save.

[Sebastien Bacher (seb128)]

Thank you for your bug. Does it happen only on fat32? Do you have a way to trigger the bug? Are you sure than no other program is touching the file? Might be something similar to http://bugzilla.gnome.org/show_bug.cgi?id=409374

[Rebecca Palmer (rebecca-palmer)]

Nothing else was running that should have been writing to the files, though I don't have any actual file stats from the bug. I've only seen it on FAT32, but since I don't have a way to reproduce the bug, this may simply reflect the files I edit most being stored there.

At least some occurrences were after another process had *read* the file (as in the Gnome bug you refer to), but I was unable to deliberately cause the bug this way.

While testing this, I noticed that the two files I had seen this bug on both had all zero access times, which were also before their modification times:
:~$ stat windocs/firefox2-error.txt
  File: `windocs/firefox2-error.txt'
  Size: 153459 Blocks: 320 IO Block: 32768 regular file
Device: 301h/769d Inode: 1174 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 46/ plugdev)
Access: 2007-07-20 00:00:00.000000000 +0100
Modify: 2007-07-20 08:47:52.000000000 +0100
Change: 2007-07-21 16:41:33.000000000 +0100

However, the bug hadn't occurred the last time these files were saved, and didn't when I tried this file again, which also changed these access times as normal.

[Rebecca Palmer (rebecca-palmer)]

I haven't seen this again since reporting it, after seeing it several times shortly before.

The all 0s access time now appears to be normal-everything on FAT32 that hasn't been accessed during that session has it.

[Sebastien Bacher (seb128)]

closing then, feel free to reopen if you get the issue again and figure a way to trigger it

[Ariel P (gasdafantauva)]

This question describes a very similar problem:
https://answers.launchpad.net/ubuntu/+source/gedit/+question/18405

Instead of fat32, the problem is with samba.

[Sebastien Bacher (seb128)]

could you describe steps to trigger the issue?

[Mikael Grön (mikael-gron-nobless)]

I have the same problem.
Running Ubuntu 7.10, gedit 2.20.3.

I use cifs mounts to all our business network resources and the problem occurs on all files I've tried throughout the LAN.
Every time I've saved a file gedit (within a few seconds) warns that the file's been changed since the last edit and asks if I wish to re-read it.

<snip fstab>
192.168.1.71:webwww /mnt/web-www cifs
</snip>

Let me know if there's any other information I can provide.

[André Pirard (a.pirard)]

I confirm Rebecca's report.
As I'm deep testing 8.04a4-6, I gedit files on an external fat32 USB drive and it happens exactly as she says : occasionally, saving, or rather wanting to save, a long time edit file (typically dormant behind a background tab) will produce that message.
But the file is saved all-right.
Only thing unusual is USB 1.1 (slower (as a network is?))
(Ubuntu's fitting an old компьютер сюрприз gift to a Belarussian kiddie!!!)
Mikael's experience looks more like bug 34813.
Might be worth the trip?
'cause of course, the question is : would the cause be the same?

Can probably be reproduced with the same setup ... and patience.
Else, what could we do to help?
After what test does gedit issue this message?
What procedure could be used to spy gedit?
I would if I was told.

Could this bug move to "confirmed"?

André.

[André Pirard (a.pirard)]

I can say that the situation is "sticky".
That is, once gedit alledges that the file was externally modified, it will continue to do so if one selects "Don't save" and tries to save again (and again).
This said, I investigated a case and I attached a log showing :
- the time and time stamps of the file -- named servers -- and its backup
- that the file had not been touched for more than 3 hours since gedit had saved it last and kept in memory (editing)
- that I made a copy t of servers before I "so dangerously" saved it
- that the diff between t and servers was removing a few null lines
- that this is exactly the modification I made to servers before saving it
- that, hence, the contents of server had not been changed despite what gedit says

I just figured that a similarity between FAT32 and smb is non-Unix timestamping.

Hoping this will help.
André.

[Sebastien Bacher (seb128)]

could anybody having the issue sent that to bugzilla.gnome.org directly? you are better placed to reply to their comments than somebody who doesn't get the issue

[Pedro Villavicencio (pedro)]

leaving this as incomplete until someone send it upstream.

[Sebastien Bacher (seb128)]

Nobody sent the request upstream, closing the bug for now, feel free to reopen if you still have some interest in the change and wants to open the bug on bugzilla.gnome.org too

[André Pirard (a.pirard)]

On 11/08/2008 11:52, Sebastien Bacher wrote:
> Nobody sent the request upstream, closing the bug for now, feel free to
> reopen if you still have some interest in the change and wants to open
> the bug on bugzilla.gnome.org too
>
> ** Changed in: gedit (Ubuntu)
> Status: Incomplete => Invalid
>
Does that mean that one full year after reporting the problem using the
procedure Ubuntu asks us to use, the answer is "we just don't care?".
Does Ubuntu *really* want users to cooperate?
We're waiting in hope to help Ubuntu and ...
One full year after, the bug is still there and it's something serious
because it accustoms users to give bogus answers to bogus messages at
the risk of giving bogus answers to correct messages.

[Sebastien Bacher (seb128)]

the issue seems to be trigger only on some special setups and it should be sent to the people who write the software on bugzilla.gnome.org, nobody having the issue seems to be interested in doing that though that's why the bug has been closed

[André Pirard (a.pirard)]

On 2008-08-12 12:07, Sebastien Bacher wrote :
> the issue seems to be trigger only on some special setups and it should
> be sent to the people who write the software on bugzilla.gnome.org,
> nobody having the issue seems to be interested in doing that though
> that's why the bug has been closed
>
> (fat32) Unexpected "file modified by another process" warning
> https://bugs.launchpad.net/bugs/125887
>
The so-special setup you speak of is editing files on any FAT(32) disk
(eg USB Ramdrive) !!!
Is that really to be advertised as beyond the capabilities of Ubuntu?

Please note that some people even dare try to edit files on SMBFS !!!
And they're having the same kind of problem, described in Bug #34813.
On FAT32, the message is issued only if the file has been open in gedit
for quite a time, though.
I dropped Bug #34813 a note drawing the attention on the similarities
between the two bugs.
But they continue to mention SMBFS/CIFS exclusively.

Bug #125887 might at least be set to be a duplicate of Bug #34813
instead of "Invalid".
If only Bug #34813's title was changed to include FAT(32) too.
> Your comments, bug reports, patches and suggestions will help fix bugs
> and improve future releases.
By closing bugs?