I was using Acidfree version 4.7 and now I upgraded to version 5.x During upgrade process everything run smoothly. As expected, script was running quite long - mainly due to moving photos to another location. Previously, images were under files/active/0 directory. Now they are under files/images directory. That's OK, but I noticed, that files were renamed during this upgrade process. They are now named like this: files.preview_0 to files.preview_1344 and also files.thumbnail_0 to files.thumbnail_1344. Strange is, that NO file has extension! Anyway, albums are working, everything is OK, but if I look into files/images, no image moved there during upgrade process has extension. New created images are properly named like originalname.extension. I would survive lost of extensions, but if some user downloads such a file, file is saved without extension and users are confused.

lakyljuk

Comments

Urfin Juss’s picture

Urfin Juss commented

What version Image is used by you?

lakyljuk’s picture

lakyljuk commented

I used latest dev version, but it was the same with 1.2 version and 1.3 version od Image module. This makes me think it's not related to Image module, but I can be wrong of course.

lakyljuk

Urfin Juss’s picture

Urfin Juss commented

Possibly you have taken advantage of function Import, the module Import of images? I had a same problem in version 1.3 In version 1.2 I did not use this function. Has now established last dev the version http://drupal.org/node/105536 and all normally works. Try to load the images once again. And it is necessary to get rid of these files. Remove them. They are not replaced new. Necessarily execute a script http://www.mysite/update.php after installation of the new version of module Image.

lakyljuk’s picture

lakyljuk commented

You mean leave only Image module activated and turn off Image import submodule? Do you think it's problem? I deleted all imported files and tried again with latest dev version of Image module, but after finishing upgrade of Acidfree, in images directory I see the same distorted files without extension as before.

lakyljuk’s picture

lakyljuk commented

I have started with my upgraded 5.1 drupal web. Acidfree disabled. Installed latest dev Image module, run update.php. Disabled Image import and Image attach. Configured Image, saved. Then enabled latest Acidfree module. Run update.php. During upgrading of Acidfree from 4.7 to 5.x version files are moved from files/active to files/images. After update.php finishes, no errors reported, AF albums works great, AF inline filter works great, but when I look into files/images, I still see wrong filenames without extension, named like ".preview_xxx." and ".thumbnail_xxx."

Any new file imported via Acidfree or imported via Image module itself is stored correctly, filenames are composed of original filename with suffix ".preview" or ".thumbnail" and also with correct extension. This error only raised during upgrading AF from 4.7 to 5.x.

Like I sad, no problems with Acidfree, even if filenames look like this, but when users are saving images, they are confused with unknown file type.

lakyljuk

Urfin Juss’s picture

Urfin Juss commented

Probably it was necessary to remove images through Drupal instead of through FTP. The matter is that references to images have remained in a database. If you have huge quantity of images it is possible to try to import them anew. At me such problem was done only with import module Image_Import. With AF such problem was not.

vhmauery’s picture

vhmauery commented

I am not seeing this problem. All the upgrade testing that I have done results in a perfect upgrade. There are no bugs in Acidfree.

But seriously, there is something different to your setup than in mine which is causing this. I run a pretty clean site with a minimal number of modules, so I often don't see the interactions that a lot of other people see. One thing you can try is to disable all the modules that are not required by Acidfree. To do this, disable all your modules, run the upgrade, go to admin/build/modules and enable *only* Acidfree. Then it will ask you if it is okay to enable other modules. Then run the upgrade. If you have Acidfree videos in 4.7, it will fail and tell you to enable video, video_image and video_upload and run the upgrade again. Let me know if that works.

lakyljuk’s picture

lakyljuk commented

Hi Vernon,

I did just as you suggested. Upgraded my site from 4.7 to 5.1 according to drupal manual. Then I downloaded only Acidfree and tried to enable it. It said, that Views and Image module are required and didn't let me enable Acidfree. After I dowloaded and enabled Image and Views, Acidfree could be enabled too. In this case it behaves a little different than you said. Never mind. After enabled just these three, I run update.php. Everything was ok, galleries are ok, thumbnails are ok, but in files/images I still see files named like ".preview_xxx." and ".thumbnail_xxx.". Any new added image via Acidfree or via Image module itself is imported OK, filenames correct, so there must be something wrong during upgrade process, which moves files from files/active into new location files/images and renames them in the same time.
I am not saying that Acidfree is doing something wrong, it could be somewhere else. But difference between your and mine test site is obvious - you work and test with clean drupal 5.1 install and I have upgdaded site from 4.7 to 5.1. Who knows if this is it?

Thanks for any ideas

vhmauery’s picture

vhmauery commented

There is a special case in the upgrade code that looks for a bug that is in 4.7 (that I never managed to track down). It is looking for 'tmp' in the filename of the old. Try out this patch to see if it changes anything. It is a one-liner and it might just work.

Index: acidfree.install
===================================================================
--- acidfree.install    (revision 508)
+++ acidfree.install    (working copy)
@@ -239,7 +239,7 @@
             $fmimage = db_fetch_object(db_query("SELECT * FROM {file} WHERE fid = '{$image->$size}'"));
             // continue only if file was really found
             if ($fmimage) {
-                if (strstr($fmimage->filename, 'tmp')) {
+                if (strstr(basename($fmimage->filename, 'tmp'))) {
                     $pinfo = pathinfo($filename);
                     $fmimage = filemanager_rename($fmimage, "{$image->nid}_{$size}.{$pinfo['extension']}");
                 }

If that doesn't change anything, one thing you might want to try is to throw in a drupal_set_message("extension is: ".$pinfo['extension']); right after the line that assigns $pinfo. This way you can see if you are hitting this special case.

lakyljuk’s picture

lakyljuk commented

Accidentaly - I was thinking about the same section in acidfree.install. I thought it has to be responsible for file rename during upgrade, but I didn't know what to do with it.
I tried to replace row 242 with:

if (strstr(basename($fmimage->filename, 'tmp'))) {

as you suggested.

Also added drupal_set_message("extension is: ".$pinfo['extension']) at place you mentioned.

Upgrade run normally, but result is the same as before. But at least I can see some messages after upgrade process. There is one message for each image processed:

warning: Wrong parameter count for strstr() in d:\web\www\modules\contrib\acidfree\acidfree.install on line 242.

Which is exactly the line I just changed according your instructions. Maybe some typo? Don't know. But I think it is not the message reproduced by drupal_set_message("extension is: ".$pinfo['extension']). This function gave me no message after upgrade finished.

I think we are closing to some solution, but some changes need to be done.

Thanks for your time and hope we can fix it.

vhmauery’s picture

vhmauery commented

As I inspected the code a little bit closer, I found that I had a big typo. :) This patch fixes the typo and has a good chance of fixing your problem.

Index: acidfree.install
===================================================================
--- acidfree.install    (revision 508)
+++ acidfree.install    (working copy)
@@ -240,7 +240,7 @@
             // continue only if file was really found
             if ($fmimage) {
                 if (strstr($fmimage->filename, 'tmp')) {
-                    $pinfo = pathinfo($filename);
+                    $pinfo = pathinfo($fmimage->filename);
                     $fmimage = filemanager_rename($fmimage, "{$image->nid}_{$size}.{$pinfo['extension']}");
                 }
                 $old_path = filemanager_create_path($fmimage);
lakyljuk’s picture

lakyljuk commented

Damn, I was so excited this is a solution, but it isn't. Everything is still the same. But I only applied LAST change, the previous one I didn't applied. Or they should be applied both? I try to combine your last change with drupal_set_message("extension is: ".$pinfo['extension']);, if it is doing something or not.

lakyljuk’s picture

lakyljuk commented

Hmm, still no go. I repaired row like this: $pinfo = pathinfo($fmimage->filename); and after this row I added row:
drupal_set_message("extension is: ".$pinfo['extension']);. But after upgrade done, I saw no such messages, only that upgrade was successful. Filenames still has no extensions. This make me think that this part of code isn't used at all. But in code I don't see any other renaming function similar to this. It should at least display "extension is: ", but is didn't show anything.

lakyljuk’s picture

lakyljuk commented

Hi vernon,

still no idea? I tried many times, but problem is still there. And as I wrote in previous, I cannot see any messages "extension is:".

lakyljuk’s picture

lakyljuk commented

Hi.

Seems noone has this problem too and no solution came up until now. So I did it my way - I batch-renamed all files in files/images directory from ".preview_xxx." to "preview_xxx.jpg". The same for thumbnails. And also I used some REPLACE and REGEXP commands in my database to rename strings in files table, column filepath. Now everything is ok. New added images has proper filename format, so I think I could be satisfied. We didn't found source of this bug, but never mind :)

vhmauery’s picture

vhmauery commented
Status: Active » Closed (fixed)