[Top][All Lists]

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

Re: [Gnumed-devel] Exiting / quitting GNUmed and patient privacy (tempor

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Exiting / quitting GNUmed and patient privacy (temporary files)
Date: Wed, 2 Jan 2008 09:37:19 +0100
User-agent: Mutt/1.5.17 (2007-11-01)

On Tue, Jan 01, 2008 at 09:52:12PM -0800, James Busser wrote:

> (but other examples might be areas of memory)
That should not happen. In-memory parts of documents may end
up in on-disk swap space but there's nothing sane we can do
about that short of suggesting competent server

> Is it agreed that the temporary files, such as those that result from 
> viewing archived documents
> and which get written into the current user's directories
>       /tmp
> and particularly into
>       /tmp/doc  (examples appended)
> are important to automatically delete?

> If yes, should code to achieve this be included at each branch where a user 
> may quit (or exit) GNUmed? This should include when a user hits an 
> unhandled exception because the user might choose to keep running GNUmed, 
> which might become unstable and prevent a controlled exit.
Yes. The entire reason we save those files into
~/.gnumed/tmp/ instead of the system-wide /tmp is to gain
more control over the situation and enhance privacy.

Deletion is not entirely trivial, however: We cannot simply
empty tmp/ when a client quits because other clients of the
same user may still be running. I have a conceptual solution
to that for 0.2.9, however. We cannot delete tmp files
straight after calling their viewer because that viewer may
still be running alongside GNUmed displaying the document
until the user choses to quit that viewer or close the
document within it. We have no control over that.

So, even if the client at startup checks ./gnumed/tmp/ for
stale <process ID>/ subdirectories (whose clients identified
by their PID do not run anymore) it is not entirely safe to
delete those: A viewer might still be displaying a file from
within such directories. The only safe solution is to
encourage admins to emtpy the users's .gnumed/tmp/ during
machine boot which, again, is a local policy issue. And even
that is not sufficient for rarely-rebooted machines.

> On the Mac, the bundled GNUmed .app can exit in any of a few ways:
> 1. From the Python menu, selecting "Quit", though I do not know if that can 
> communicate to a running Python program to prompt an orderly exit.
> 2. Clicking the GNUmed client window's red "close" button
> 3. Hitting the unhandled exception dialog, and clicking the "Close GNUmed" 
> button
> 4. An uncontrolled crash or freeze-up (or force-quitting).
> In *most* circumstances, methods 1-3 fully exit Python (though there have 
> been cases where Python remains loaded and its "Quit" menu, despite being 
> selectable, achieves nothing giving me no choice but to force-quit it.

Except for a hard crash we'll get some actable-upon
notification of shutdown.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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