[pmwiki-users] Re: Re: Re: Using AllRecentChanges as a shared page between fields
Joachim Durchholz
jo at durchholz.org
Mon Jul 25 03:47:19 CDT 2005
Patrick R. Michaud wrote:
> On Mon, Jul 25, 2005 at 12:10:31AM +0200, Joachim Durchholz wrote:
>
>>> 2. Because cleanup processes sometimes come in and destroy the
>>> files in /tmp, which isn't always helpful to PmWiki.
>>
>> "not always helpful" would be an understatement, but the cleanup
>> processes don't delete files that haven't been touched in days. I'd
>> assume that PmWiki doesn't need its temporaries around for such a
>> long time - or does it?
>
> They aren't always "temporary" -- sometimes PmWiki needs a scratch
> pad where it can store data across invocations.
That's work data. It might properly belong to the page store (i.e.
wiki.d/), or it might be a field-specific thing, or it might be
installation-wide.
It's definitely not "temporary" anyway :-)
> For example, the .lastmod file is used to help manage browser page
> caching (and soon page formatting), but .lastmod might not be updated
> for a very long time if there aren't any updates. If the file
> disappears it won't cause things to stop working, but it does mean
> that PmWiki will stop making use of caches, because it has no idea
> when the last modification took place. (Similar arguments can be
> held for .mailposts.)
Yup. Work data.
>> I'm got a PAM module installed that sets up a separate directory
>> for each process in /tmp. This eliminates race conditions that are
>> otherwise commonplace around the creation of a temporary file.
>
> Of course, this would also invalidate PmWiki's purpose for having a
> work directory, which is to allow one process to easily communicate
> status information to other later processes.
Such information indeed doesn't belong to the $TMP directory. $TMP
should carry information that is created and no more used within a
single transaction. Intermediate semi-converted files belong into that
category.
Regards,
Jo
More information about the pmwiki-users
mailing list