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: Torsten
Subject: Re: How to properly save file in GUI
Date: Wed, 07 Nov 2012 20:51:42 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

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.

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.

Torsten




reply via email to

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