marcus.harnisch at gmx.net
Sun Jul 5 11:17:37 EDT 2009
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> In a world where you pass temporary files to an *unknown*
> third-party application running asynchronously, you cannot know when
> the temporary file becomes unnecessary.
Everything created below $TMPDIR is temporary by definition. Temporary
files should be deleted when the creating application believes the
file is not needed any more or when the creating application exits
(but see below).
tmpreaper is really only useful for cleaning up the mess after an
application has received SIGKILL. And that would only affect temporary
files created in some standard location anyway.
> On the other hand, how is xdg-open supposed to know that the file is
> have received is temporary, and may be cleaned up? How is the
> actual viewer application supposed to know? There's no protocol for
The invoked application should never explicitly remove a file which
has not been created by the application itself. Obvious exceptions are
programs like /bin/rm, etc.
On Windows, the invoked application would keep the file open if
needed, effectively preventing removal. Don't know if this is default
behavior or whether there are some switches needed when opening a file
(I have not the slightest clue about the Windows API and no plans to
change that situation either). At some point XEmacs would try to
remove the temporary file and silently ignore errors.
On Unixoid systems, the directory entry of a file will be removed when
the file is deleted so that it effectively becomes non-existent. The
invoked application however, for as long as it holds a file handle,
can access the file normally since the inode still exists. The
physical file disappears automatically as soon as the application
releases the handle. Again, XEmacs deleting a temporary file is not an
issue as long as the invoked application had a chance to grab it while
the file still exists.
> > xdg-open ought to be able to wait for the launched process to
> > terminate. It is actually arguable whether it should wait by
> > default, although this is not likely to change.
> This doesn't work in a document-is-window world where programs like
> Firefox and OpenOffice allow only one instance of themselves to run at
> a time, and additional instances which are started just hand off
> responsibility for new documents to the existing instance. Like
> xdg-open itself, the viewer process is often ephemeral.
The /real/ trouble here is that there is a race condition between the
ephemeral process exiting before the application has actually opened
the file. If that'd be dealt with properly, we wouldn't have this
discussion. No need for a protocol really since all this is
intra-application. Just some common sense needed on the developer's
xdg-open calls e.g. gnome-open calls <application> and returns if
<application> returns. If <application> returns before owning the file
this is not xdg-open's fault and neither gnome-open's. It is some of
<application>'s developers who screwed up.
> Really, XEmacs ought to detect when GNOME or KDE or Windows or Aqua
> is present, and refuse to start at all on the grounds of gross
> negligence in design of the environment.
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]
(seen on http://www.veripool.com/verilog-mode_news.html)
More information about the XEmacs-Beta