[pmwiki-users] thumblist, jpg.jpg.lock

[Petko Yotov]

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");