Jerry James writes: Whether or not to remove temporary files should be an option of browse-url anyway. It seems to me that a 3-way option should be available: - fetch to $TMPDIR then view and finally clean up - fetch to $TMPDIR then view - fetch to $SAVEASDIR then view xdg-open should be special-cased to either never clean up, or (if it accepts URLs) configured to do the fetching itself, thus delegating cleanup to it or its inferior process. This is just too bad for platforms without tmpreapers. xdg-open can't be that complicated. (Er, can it? :-þ) If it's GPLv2-compatible, we could fork our own version (and keep it in lib-src a la oobrowser). If we do it as an option, we could contribute the patch upstream for them to do as they see fit. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Jerry James <james(a)xemacs.org&gt; writes: Coincidentally, I have just tackled the same issue on Win32 ("start /wait"). It is a nice feature to have though. In a far, idealistic future, it could help making mailcap.el a lot smaller. A well behaved application should clean up after itself. 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. Regards Marcus -- 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) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: 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. 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. 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 end. 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. He he... Regards Marcus -- 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) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Hi Stephen "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Not deleting files in $TMPDIR when an application exits, based on some unfounded claim that a certain application doesn't exit is silly. By that logic, I'd claim that since I never reboot my PC (I don't even log out), a "tmpreaper" would never get a chance to clean $TMPDIR. Unless run via a cron job, that is, which would still derail applications accessing files in $TMPDIR. And no, checking atime does not help either. There simply is no perfect way. Only a simple list of file names would be necessary, each (file name) element of which would be unlinked when XEmacs exits. To protect from the biggest blunders the expanded names could be required to be relative to $TMPDIR. If *your* XEmacs doesn't exit -- fine, you'll have the same behaviour as you proposed with not deleting files at all. But those who do occasionally exit XEmacs will have $TMPDIR ridded of all residue XEmacs created. Best regards Marcus -- 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) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta