infinite duplicate files in files/image folder

same situation here. When the image size < preview size, it happens.

It has been reported here: http://drupal.org/node/51600

But I applied same patch and it doesn't work.

I need help too.

grrrrr
I m annoyed by this problem.
I need some suggestion....
thx.

I ve tested again and again but I found it didnt hapen every time
just some special pictures may cause this problem but I dont know why these pictures would do this

this sounds scary. having the same problem. i didn't inspect the modules code myself, but if you say this is caused by "special" images, maybe we should gather information about these images.

but if the older version worked well, then what where the changes that caused that problem.

I m sorry for deleting the "special" picture

Last time I found over 200 copies of a picture and deleted them all. but these days i tested again and there was no error to happen

I m trying to do some more test

An explanation of what's happening:
http://drupal.org/node/75238 (from July 2006)

nicely explained, but the patch included in that post is for the 4.7 version of the image module, and won't work as supplied for the 5.1 version.

Would somebody who has a clue about the internal workings of image please fix things?

Many thanks.

I tried a quick'n'dirty workaround: I added a 2px wide border around the original images and copied these changed files to the files/images directory.

This didn't work: every time I view one of these images I get yet another preview_##.jpg.

Another quick'n'dirty workaround (in mysql):

UPDATE files
   SET files.filesize = files.filesize+1
 WHERE filename = '_original'

That didn't work either. Or, the code worked, but the bumpf just keeps on appearing.

This is a major showstopper.

What version of PHP are all of you using?

That's php 5.2.0 and php 5.2.2.
The problem is present with both.

I'm a bit confused.. this is already fixed in 1.2, isn't it? I've had the problem, but I think after updating to 1.2 it was fixed.

i wonder if this is the same as http://drupal.org/node/133649

I'll also note that #133649 has a patch...

Though reading closely though some of the comments it seems that there are a few issues at play. Everyone should grab the latest -dev release, visit the admin/settings/image page, save the settings, and see if the issue is still occurring.

well assuming that the problem is that people haven't saved their settings form--which sets a last updated date which gets compared to files to see if the derivative image sizes have been changed and derivative images should be recreated.

the following removes the check to regenerate old images.

Tested: I downloaded the latest dev, added this patch and saved the image settings.

This patch fixes two issues:

You won't get infinite copies of preview in the default image folder.
Image derivatives aren't regenerated on every view. (issue http://drupal.org/node/151733 )

Testing further:
There are no problems with image import.
Deleting a few thumbnails and previews got them regenerated into the default image folder, which is as it should be.

Many thanks!

A problem of gallery (and similar) showing only the top 4/5 or 9/10 or so of thumbnails and previews was remedied by saving the image settings, deleting all derivatives, and regenerating the lot ("view this gallery. Then view the next one. And the next one. And the next one ..."). (It's entirely possible that I was having this problem because I use directories in my images folder.)

This patch means that image now has some sort of directory support: first import the lot, then update files.filepath (manually or using php, whatever you like), then move the original images and their derivatives into the various folders you've specified for them in files.filepath. Lovely! (issue http://drupal.org/node/147668 )

Hetta, glad to hear it works for you.

Here's an updated patch that applies cleanly to the current version.

I wasn't too sure if this is the right way to go. The automated rebuilding of thumbnails was pretty neat, but it's kind of a support nightmare. Now that you can manually use the "rebuild thumbnails operation" I think we can do without this.

to you both, thanks for that useful information

I actually saw that I'm running a bit older 5.x-1.x-dev on berlinerstrassen.com that has this issue fixed.
I hope I'll find a good update path ^_^
Gonna check your suggestions first, in a few days.

Trying to import images with the latest .dev and the updated patch gives:
"Fatal error: Call to undefined function db_queryd() in /srv/www/htdocs/hhhdr/sites/all/modules/image/image.module on line 847" on image import.
A quick check: db_query() exists in database.inc, db_queryd() doesn't.
The same function is called on line 498 and line 849, too.

Assuming that this is a typo, I changed things from db_queryd() to db_query() and the import worked. Patch attached, it's for the latest dev + this patch.

I screwed up and committed some debugging code (the devel.module supplies a db_queryd function). Hetta posted a patch for that on #142233, which I've applied.

whoops, put that last message in the wrong window.

I accidentally committed a fix for this as part of the fix for #117915. I'd love for some people to upgrade to the latest -dev release and test the hell out of it so I can squash any last minute bugs and roll a new official release.

is there confirmation that this is fixed in -1.5 release? not listed (afaik) in release update.

.b

it should be fixed in the -dev release. please test that out: http://drupal.org/node/105536

this is to hopefully help someone in the future...

if you have a lot of these duplicates in your images folder and have shell access, you can do this once you're in the images/ folder...

find ./ -name '*.preview_*.jpg' -print0 | xargs -0 rm -f

as with any rm command, use with caution! this removes all the extra preview_# images in the folder.

if you do it as

find ./ -name '*.preview_*.jpg' -print

you can see a list of files it would be deleting...

what i've learned is that commands like rm and ls don't handle lots of files easily...

Hope this helps someone...

K. Paul Mallasch - Publisher
kpaul media