Filefied 3.5 update fails

This problem is in the upgrade path for filefield_meta. I'm not sure how to reproduce the issue however, or what would cause the problem. If any more information can be provided that would be appreciated.

Just a note, you can always completely uninstall FileField Meta and then upgrade. Re-installing FileField Meta in the FileField 3.5 version will then repopulate meta data into the database as files are individually loaded.

I think you may be right. The patch suggested in #829920-13: Error on Upgrade to 3.4 warning: Division by zero filefield_meta.install on line 166 did not get incorporated. Seems like a 3rd release may be in order. *sigh*

Hm actually I think a variant was incorporated in #19: http://drupal.org/node/829920#comment-3099868. This patch was definitely included in the 3.5 version. It's possible that you may be having trouble if the upgrade failed once but a database backup was not restored, then you tried running the update again in the 3.5 version.

I'm marking this to needs info, since multiple people have reported the update working in 3.5.

These steps might help:

1. Disable Filefield module and its dependents (admin/build/modules)
2. Remove or delete Filefield modules from sites/all/modules/
3. Install System Table Cleaner module, then delete (if any) Filefield related database tables the module finds.
4. Reinstall Filefield modules.
5. Run update.php

Hope it helps. Thanks quickskecth for the great modules and responsiveness.

How is one supposed to deal with this module - i have been using it for uploading thousands of files each with a unique description - in D5 and it worked flawlessly, . Now the description is lost on every upgrade in D6 - and the last one failed completely: 3.3-3.5.

SO, uninstall the module, clean out all database info and reinstall?????

"£$%^&*(8&&^^%$%%(frustrated)

Something similar:

upgrade and then upgrade.php => never ending & on escaping many error messages about filefield meta something like line 166 (not sure).

Disable Filefield module and (ALL THOSE MANY/) its dependents ... (etc)

Very nice, but that's why I lost my life website a month ago now and still not back again. BECAUSE I'm installing first all modules WITHOUT any info, theme nor block or whatever. So I can eliminate erroneous modules first, so I can't loose my website and info during that process...

Murpheys law; if something can go wrong it will. But combined with Drupals law: modules from time to time always give these kinds of errors + having many modules => often gives an unworkable website.

Have these problems 3 years now with Drupal and never succeeded to build a complex (module rich) site, because almost by these combined laws, its impossible. But I grew in these years and found ways to break Drupals laws, so I dream to commit the perfect crime on short term and have a WORKING module rich Drupal site in maybe one or two months.

OK, de-installed filefield 3.4 and several dependencies. Uploaded filefield 3.x DEV (but nowhere I could find that the patch is included, not in 3.5 nor in 3.x dev, but the dev is from one day later, so maybe?)
=> extract => check for extracting errors =>

ehh, no, first:

Install System Table Cleaner module

I have some other module Schema (with module "diff"?) that also does something:
http://drupal.org/project/schema

=> Schema doesn't report errors for filefield (of-course; the error was that one database field was NOT created). Of-course I will install that system table cleaner module (thanks for the hint!), but for other garbage that other modules cause.

=> .../admin/build/modules => filefield already is ticked on automatically (why?), ticked on again audiofield, filefield meta, image crop image FUpload, SWF upload widget, embedded ?...

=> .../admin/content/node-settings/rebuild

=> no more errors

(but now I'm anxious what will happen on every next dev release, as I installed the dev because that is the latest release after this bug was found)

P.S.: For who doesnt want to loose its data; there seems to be a patch (look on similar recent error threads), but unclear is what it can repair in individual cases when there is a database error.

@tsbah: I can't fix the problem if I don't know how to cause it. :-(

The 3.5 version incorporated the patch pwolanin provided. So if 3.4 with the patch worked, then 3.5 should work also. pwolanin himself made the 3.5 release. If there's some very discrete way to reproduce the problem, I'm happy to test the upgrade path again. However as-is we've had multiple confirming reports that 3.5 is working perfectly. I need more information about the cause of the problem in order to do anything.

Looked back again into Modules/CCK. Filefield 6.3.4 and Filefield meta 6.3.4 are still sitting there

This frequently happens when a stray version of FileField has been uploaded into an unexpected location. You're likely still running FileField 3.4 and not 3.5. Check your "system" database table and check what path Drupal is loading for FileField, there may be a copy of FileField that it's picking up that you didn't expect.

@tsbah: Neither of those screenshots retrieve the information necessary. In the "system" table, you're only seeing the first 30 rows out of 352. Filter the list down to include only those items with name = 'filefield'. FileField does not make any of its own tables (other than the filefield_meta table if you use that module).

Yes!! See how the module being loaded is "sites/all/modules/tmp/filefield/filefield.module"? THAT copy of the module is being loaded. You can't keep extra modules under any subdirectory of "sites/all/modules" as Drupal will find them no matter how deeply they are nested. Remove this "tmp" directory and Drupal should pick up the correct copy.

Hurray user-error, better than a bug.