[pmwiki-users] thumblist, jpg.jpg.lock
Petko Yotov
5ko at 5ko.fr
Wed Apr 27 15:19:48 CDT 2016
A thumbnail is created *after* the page is saved, that is,
* an editor first writes the thumblist parameters in the wiki page,
* then saves the page,
* then the saved page reappears, but the thumbnails are not yet created,
so for every thumbnail that needs to be created:
** the recipe will create (touch) a "lock" file and
** will output in HTML a special link to the create-thumbnail action
* so when the editor sees the page, his browser will request the
create-thumbnail URL so the recipe:
** will first check if there is a lock file
** will create the thumbnail,
** will save it to the disk,
** will remove the lock, and
** will output the thumbnail to the browser of the editor.
On a subsequent (second) visit, the recipe will see that a thumbnail
exists, and will output a direct link to the thumbnail.
The thumbnails are created one at a time, each in its own (parallel)
PmWiki process, because this way each process requires less time and
less memory. The first versions of Thumblist (2006-2007) thumbnails were
created in a single PmWiki process and this proved to very often hit the
system limits and crash the process, so I changed it (and wiki admins
were happier).
A lock file is created to make sure that the thumbnail is really
requested by the editor in the wiki page. Before this, there was a
vulnerability where an attacker could use the create-thumblist action to
fill the server with thousands of thumbnails.
About your problem, I suspect the AutoPurge has progressively deleted
some of the oldest thumbnails, but users were served the cached HTML
pages with links to now deleted thumbnails.
Setting $ThumbList['AutoPurgeDelay'] = 0; should prevent this from now
on, but you may need to once revisit all your pages with the Admin
account, or maybe simply clear the existing FastCache cache, and let it
rebuild itself once again.
Now, I haven't used or reviewed FastCache, but it must not cache a page
when the thumbnail is not yet created. Thumblist issues a NoCache() call
to notify about this: I hope FastCache respects it.
Petko
P.S. This should be rare: If a thumbnail lock exists, but not the
thumbnail, this may mean that the person who edited the page, after
saving it, moved away from it, before the thumbnails were generated
(appeared in the page). Or, s/he used a text browser, and the browser
never requested the thumbnail. Or, used an ad-blocker that thought that
the thumbnail was an advertisement and stopped the browser from
requesting it. Or, the server process crashed and didn't send the
thumbnail, and the editor moved away. In any of these cases, the next
visitor on that page should generate the missing thumbnails. There may
be other reasons I haven't thought of, but probably less common.
On 2016-04-27 16:15, ABClf wrote:
> I'm using Thumblist for conveniently listing image thumbnails, with
> links to big images, using a dedicated template. Great toolbox. I have
> recently set the autopurge to 0 to be sure the program is not going to
> delete thumbnails (I use –and strongly need– the fastcache recipe thus
> I dont want the thumbnails to be deleted).
> (uploads are stored page by page).
>
> For a few pages, issue is that the thumbnail is not printed out, while
> the link to the big image is working ; only the thumbnail is wrong, as
> if there is a missing picture (I am given the empty frame for the
> thumbnail, yet not the thumbnail itself).
> If I run ?action=regen to the page, all gets better and all thumbnails
> are printed out, as expected.
> I'm willing to find out where is the issue and how to solve it.
> Please note the issue happens to unidentified users, for pages saved
> in the cache. As an admin/author, if I browse the page which doesn't
> fully work for visitors, I get all the thumbnails and, my visit done,
> the issue will be solved for unidentified visitors who are still given
> the same cached page as before.
>
> At first, I thought the culprit is the autopurge, which may
> automatically delete some images. But now I'm sure the issue has
> something to do with the .xxxx.lock extension given to some
> thumbnails.
> I have compared one directory, before regen and after regen. This way,
> I see the missing thumbnail is .locked.
> I'm not sure why this .lock extension (and dot at the beginning)
> happens, and wether is is possible to get rid of it ? Is that because
> the server has ended his thumbnailing task before it was done ?
>
> Listing directory for page 27572 when 1 thumbnail –for image named
> 27572_20cm– doesnt work :
> ./2/27572
> ./2/27572/.th200---ffffff--27572_20cm.jpg.jpg.lock
> ./2/27572/27572.jpg
> ./2/27572/.thumblist-trail.Bob.27572.1.cache
> ./2/27572/27572_20cm.jpg
> ./2/27572/.thumblist-trail.Bob.27572.2.cache
>
> Listing directory after ?action=regen, all is working :
> ./2/27572
> ./2/27572/27572.jpg
> ./2/27572/.thumblist-trail.Bob.27572.1.cache
> ./2/27572/th200---ffffff--27572_20cm.jpg.jpg
> ./2/27572/27572_20cm.jpg
> ./2/27572/.thumblist-trail.Bob.27572.2.cache
>
> In Thumblist documentation, "lock" word comes for the
> $ThumbList['EnableThumbs'] = 1; setting, which I dont use in my
> config.
>
> /config/
> # ThumbList
> $ThumbList['AutoPurgeDelay'] = 0; # to completely disable the AutoPurge
> function
> $ThumbList['UseTmpl']=1; # to always use the template ; set
> usetemplate=0 to override this eventually.
> include_once("$FarmD/cookbook/thumblist2.php");
More information about the pmwiki-users
mailing list