I tried to reproduce this bug on a Win7, 32 bit system with the official Windows build of GIMP 2.8.2. from http://gimp-win.sourceforge.net/. Everything is fine here. I clicked the placeholder thumbnail in the preview sidebar, the preview was created and still there the next time I opened the dialog. 
The permanent 'denied' error lets assume that this could either be a problem of missing write permissions or a problem with the user account control, that was much more disturbing in Vista than in Windows 7. AFAIK the image thumbnails are stored in subdirectories of $USERDIR\.thumbnails. Please check your write privileges for that directory and its subdirectories.
Can you please report the full error message here? An answer during the next 6 weeks is much appreciated.

Meanwhile reinstalled Gimp 2.8.0 for errorfree working (deleted all Versions in Programfiles and userdir, complete clean reinstall):
.thumbnails not found in userdir, only a .thumb with no new files.
Per sidebar click created thumbnails are stored (where?) for a while (in the same Gimp-Session and also after a restart of Gimp), but seems not to be saved permanently. At least gone after using Portablegimp in between .
Partially resolved with manually created .thumbnails directory in userdir, now it works with installed 2.8.0! (But missing directory should corrected in Gimp Windows Installer?)

But when portable Gimp (2.8.0 also 2.8.2) is used, when closing portable Gimp, all Thumbnails from installed Gimp in .thumbnails in userdir are deleted!
(Strange, but I can live with it.)

---

Detailed reconstruction of Gimp 2.8.2 Thumbnailcreation-Problem with Portableapps Version:
Error message: could not create thumbnail for file ... : Permission denied
(but this message is shown very unregularly)

but allways:
in the file => open dialog
when click on a picturename, the thumbnail is automatically created (no need to click on the sidebar)
then something goes wrong:
even the thumbnail is shown (and remebered for future use - Thumbnails in GIMPPortable\Data\.gimp\.thumbnails\normal are created), gimp working on with no end.
the cursor shows permanent the busy circle (dancing like on steroids) and in the sidebar preview window the "preview will be created" Message does the same.

Changing to an other picture has the same result. Endless working till Opening an image or closing the open dialog.

Watching this in ProcessExplorer from Windows Sysinternals:

file-jpg.exe has many I/O Reads/Writes but results allways in "access denied";
same with file-png.exe
with .xcf files only gimp-2.8.exe itself explodes with I/O Reads/Writes but also endless.

With Gimp 2.8.0 (also portableapps Version - installed in same place with same write privileges) each thumbnail neads a separate click in the sidebar to be created (and is also correct saved and remembered), but with no endless working Gimp.

Tried to resolve/reproduce the endless working preview problem in 2.8.2/2.8.0:

2.8.2:
Setting in options dialog the size of the preview pics to a very low number (e.g. 1 kB) kills the automatic preview (but of course needs now separate click in sidebar for each picture), but shows stable results without endless working Gimp.
(Like in 2.8.0)

2.8.0:
Setting size of preview pics above the standardized shown 1.3 GB (e.g. 2 GB) brings automatic preview (no need to separate click on sidebar), but also WITHOUT endless working Gimp afterwards.
(Unlike 2.8.2!)

So the problem must be in a change from 2.8.0 to 2.8.2 in connection with the automatic preview!

The problem you're describing is the behaviour of the workaround for the 1.3 GB file size problem (see bug #669818). We already have an eye on it. 
I remember this behavior from Partha's 2.8.1 Windows build, but couldn't reproduce it with the 2.8.2 build from gimp-win.sourceforge.net. 
Secondly the combination of the installed GIMP and Portable GIMP (which is not supported here) seems to be the cause of the error. Could you work with just one of those?
To comment #3: you can select more than one file in the file list and click into the right pane to get the previews. This saves you from selecting each single file.
IMHO we should close this bug, if you can live with the proper settings in the Preferences dialog. Your answer during the next 6 weeks is appreciated.

1) Workaround for 1.3 GB problem is OK for me.
2) Portable Gimp is not you problem, I agree.
3) The new endless working problem in 2.8.2 is a real problem, if not fixed in future versions!
I see this problem with installed 2.8.2 Gimp (from your official source), Parthas portable 2.8.1 and PortableGimp 2.8.2 (on Vista + Win7).

Of course I can kill the automatic with my 1kB workaround, but without this measure each openenig of a picture sounds, that my computer will kill himself if nobody stop his endless working!

That can not be the future of a so called "stable" Gimp!

So, please don't close this bug until solved this problem!
(Despite the wrong sizeinfo, it was OK in 2.8.0!)

To say it clear:
I like Gimp (since single-window-mode ;-) and think, it is the best free tool for serious picture manipulation.
But I know, that bugs and imperfections in software are a part of life. Personally I'm happy, if I found a workaround.
e.g.:
*) not working color picker in "color to transparency" in layers dialog => select color before with main tool color-picker and then get it with right-click on color in the "color to transparency" dialog; OK
*) scrollvalues in brushsize are worth 0.01 Pixel - much too small for proper working => page up / page down keys scolls +/- 1 Pixel; OK
*) wrong sizeinfo in Picture opening dialog => pictureworkflow starts with an imageviewer before; OK

But I'm working as consultant and softwaretrainer and advises many other people to use certain software. (Also Gimp!)

If somebody installs Gimp without the obove workaround knowledge - not really bad.

But a bug like the endless working problem in picture preview (in standardconfiguration after installation of 2.8.2), which affects the whole computer in an at least worrying manner, needs really to be solved in future versions!

Stated in full respect for the great work of all gimp developers!

I may have the same problem.  When I try to load a file in Windows GIMP (XP / 2.8.2), the fileopen dialog does generate a thumbnail, but continues re-generating it as long as the dialog is open.  The thumbnail panel on the dialog is constantly switching between "generating preview" and "preview is out of date" at a rate of 5-10 times per second, continuously.  The most immediate (and most harmless) result is that my mouse cursor is constantly toggling between the "normal" arrow pointer and the "working in background" pointer (normal pointer with added hourglass).

I haven't attempted to save or export any files yet but this constant re-generation of the same thumbnail over and over while the dialog is open could very well lead to file access errors.

Somebody who is able to hack windows will have to track this down.

Burnuser, no need to worry and thanks for your workarounds ;-)
I amended bug #676708. 
For the scrollvalues in brushsize I didn't find a matching bug. If you know the right bugs number, can you please amend it with your findings or otherwise file a new bug with a proper description and your workaround? Thank you.

Burnuser, indeed thanks for the workarounds, but as to "needs to be fixed
in future versions", this is simply not going to happen because
we have close-to-zero windows developers.

So if you know somebody who is really interested in fixing this,
bring them here, or nothing will happen.

@ strata_ranger: Thank You for your confirmation of my findings (Yes, I'm not crazy, it's a real bug!)

@ Sven Claussner: scrollvalues problem and workaround filed as new bug #683553

@ Michael Natterer: I know about the lack of windows developers (and programmers in general), but have no direct solution for this problem.

But maybe some ideas ...

*) Google Summer of Code 2013

*) Gimp Cooperation with schools/universities in programming projects

*) Eventually could company sponsors help, with interest in a well known working windows tool (e.g. Microsoft for Windows 8) or a working Photoshop alternative (e.g. Google) or a foundation/society/authority in the field of education, ...

I know, Gimp is traditional a project of a few volunteers, but a such important and grown project needs you (and other key developers) in the future also as successful fundraisers and ambassadors of the great gimp-vision!
(See yourself as Gimp Top-Manager and think big in getting additional ressources!)

Only ideas, but if the pressure on few Gimp coredevelopers is growing with no end, maybe a systematic management solution could help. Eventually worth a discussion at the next Gimp coreteam meeting ...

Best wishes for you and your great work ... and may the Force be with you :-)

Thanks, burnuser, for the missing information. Your proposals sound good, but Bugzilla isn't the right place for discussions unrelated to bugs. I remember, there were similar proposals and discussions on the mailing lists already. Please read these discussions first and post your thoughts there, if you find, they add something new. And - as you know - the GIMP team is very small, so if you like, any active help is welcome...

Yes indeed, people who think for themselves are always welcome. The
force is strongest on IRC :)

*** Bug 689406 has been marked as a duplicate of this bug. ***

*** Bug 686947 has been marked as a duplicate of this bug. ***

Hopefully fixed in master and gimp-2-8:

commit 4d2316cb3e0395a57821c461135b2e3e3788408d
Author: Michael Natterer <mitch@gimp.org>
Date:   Fri Jun 28 22:44:19 2013 +0200

    Bug 683152 - Preview thumbnails in file open dialog causes error in 2.8.2
    
    Port gimp_thumb_file_test() to GIO which seems to get its stat()
    calls right on all platforms.
    
    (cherry picked from commit bb755960620ad648a264a99b5edb67357c513e04)

 libgimpthumb/gimpthumb-utils.c | 67 ++++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 46 insertions(+), 21 deletions(-)

*** Bug 703329 has been marked as a duplicate of this bug. ***

*** Bug 705209 has been marked as a duplicate of this bug. ***

I tested with Mike Hennings nightly builds of GIMP 2.8 and master from
3.10.2013 on Windows 7 (32 bit) and Windows 8 (64 bit). The bug doesn't occur
anymore - ok.