octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to properly save file in GUI


From: Daniel J Sebald
Subject: Re: How to properly save file in GUI
Date: Wed, 07 Nov 2012 15:07:38 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 11/07/2012 01:51 PM, Torsten wrote:
On 06.11.2012 20:07, Daniel J Sebald wrote:
Torsten and I just debugged a "file-changed-on-disk" problem in a
GUI-related changeset.  Nothing major, but I want to open this issue to
the wider group for someone that might have more system-level experience.

The issue is that when saving a file in the GUI editor unless the file
name is removed from the file watcher list (the watcher is a Qt class),
the GUI action of saving the file will be seen by the watcher as a
change-on-disk and a notice will be created.  No problem, simply do the
following:

1) Remove file name from watcher list.
2) Open the file for WriteOnly
3) If the file fails to open, put the file name back on watcher list if
it was there and stop.
4) If file opens successfully, save the contents of the edit area into
the file.
5) Flush and close file.
6) Put the file name into the watcher list.

So, the above generally works, but if one thinks about it, there is an
ever so small window of time between step 5 and step 6 where the file is
not being watched.  On a multi-threaded system it isn't inconceivable
that a process could overwrite the file between step 5 and 6 and the GUI
might miss that.  In normal operation it seems inconsequential as the
odds of this happening are minuscule.  However, one never knows the
application and someone could have a background process running that
often writes a data file that someone is watching and working with in
the GUI file editor.

So, I'm wondering if there is some proper way of sequencing things here,
or maybe another approach.  Two things I can think of:

A) Temporarily change the to-be-written file to read-only on disk.  This
would prevent some other application from overwriting, possibly causing
a conflict and trouble for another application.

B) Never remove the file watched from the watcher list.  Instead, save
the contents of the editor tab to a temporary file and note dMethos etails
about that file such as exact time the file was saved.  Then, replace
the to-be-written file with the temporary file.  That will cause the
file system watcher to issue a signal and the slot can then check if the
time stamp matches that of the temporary file.  If so, do nothing,
otherwise issue a "file-change-on-disk" notice.

Am I being overly cautious?  Is there a more common method I'm
overlooking?  Option B seems appealing, but does it have flaws as well?

Dan

PS: As I write this, I realize that not only do we need to account for
file changed on disk, but also file deleted from disk.  There's no sense
in reloading a file that has been deleted.

The time window where the file is not watched even starts directly after
1. From my knowledge, open () does not open exclusively and the file can
still be overwritten without any warning.

Yes, could be. Sort of a race condition depending on which process saves the file first and last in that window.


In method A, the gui itself needs write permissions for writing the file
so we can't set read-only all the time? Method B sounds good to me.

Somehow that is feeling like the more correct, more robust route to go to me as well. I'll work on changing that sometime in the next day or two.

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]