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 administration.
> 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? Yes. > 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. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
