| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | D7 upgrade path, D7csmtl |
Issue Summary
Here's what I did:
Installed a module in sites/default/modules.
enabled it.
copied it to sites/all/modules.
disabled the module
rm -Rf sites/default/modules/mymodule
refreshed the modules page, it is there, ready to be checked.
check it off, and hit submit.
Here is the error:
* Warning: filectime(): stat failed for sites/default/modules/permission_select/permission_select.module in _registry_parse_files() (line 127 of /Users/jacob/work/github/drupal/includes/registry.inc).
* Warning: filemtime(): stat failed for sites/default/modules/permission_select/permission_select.module in _registry_parse_files() (line 128 of /Users/jacob/work/github/drupal/includes/registry.inc).
* Warning: file_get_contents(sites/default/modules/permission_select/permission_select.module): failed to open stream: No such file or directory in _registry_parse_files() (line 132 of /Users/jacob/work/github/drupal/includes/registry.inc).
* PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'filectime' at row 1: INSERT INTO {registry_file} (filectime, filemtime, filename) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2) ON DUPLICATE KEY UPDATE filectime=VALUES(filectime), filemtime=VALUES(filemtime); Array ( [:db_insert_placeholder_0] => [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => sites/default/modules/permission_select/permission_select.module ) in _registry_parse_files() (line 144 of /Users/jacob/work/github/drupal/includes/registry.inc).
I don't have time to investigate, but this is pretty bad IMO, and a release blocker.
Comments
#1
You need to move, not copy. When you are disabling module in your steps, you have 2 same module(duplicate)...
#2
Follow the steps I took, this is in fact a bug.
#3
The filectime stuff was added in #513592: Simpletest 7 much slower than 6.
#4
@JacobSingh
the correct way is to:
first disabled the module
then copied it to sites/all/modules.
rm -Rf sites/default/modules/mymodule
if you can get the bug when following the correct procedure, it is critical, otherwise, it's not critical,
#7
@alexanderpas.
Try it please posting like I'm just making noise. I'm not BSing you.
In fact, try this:
Put a module (any module - let's do permission_select) in sites/default/modules.
Install Drupal 7.
Don't even enable it.
Now cp -a to sites/all/modules.
Now rm -Rf sites/all/modules/permission_select
Not go the modules listing page. It shows up. Now try to enable it.
#8
@JacobSingh
Have you tried emptying your cache after copying the module but before enabling it? I'm pretty sure that Drupal caches the location of your modules...
#9
Exactly, and that's probably the bug. Core used to clear its caches when you looked at the modules page, now it only does it after it has been submitted.
We can't expect users to clear their cache or get a nasty fatal error when doing a normal operation after a page refresh when logged in as an admin.
We'll need to address this I think, or it could get really ugly. Perhaps we do a check on admin/config/modules for non-existant files in the system table and then refresh the cache in that particular case?
#10
Same error happens when you move a module between D6 and D7 then try to upgrade database. Attached patch stops the explosion but leaves the warnings and not very pretty.
#11
does #661420: Installation of modules is hugely inefficient remedy this issue?
#12
Haven't tried it, but I don't see anything in that patch which would fix this.
#13
Haven't tried it, but I don't see anything in that patch which would fix this.
#14
Sorry, I didn't find this issue when I was searching earlier today, since at first my bug seemed different. But, I think I found the root of this bug and have a patch that fixes it over at #683988: failure to clear the system_list entry from {cache_bootstrap} results in bogus results when you upgrade a module. Maybe we should just mark this one duplicate, even though it's older, since my new issue has more technical details and a working patch...
#15
It seems unlikely that system_list() is causing this, since it was committed a month after this issue was opened, and the caching two months after.
#16
Another thing that seems to trigger this is accidentally putting a reference to a non-existent file in your files[] array in the .info file (because of a typo, or because you fully intend to put the .install file there at some point, etc.). If you do this and save the modules page, BAM.
#17
According to #10.
#18
Since there has been no activity from registry maintainers on this issue for nearly four months, I'm marking #10 needs review as a quick fix. That would at least downgrade this to a normal critical bug rather than a site frying one. Please come up with something better before you mark this as needs work, unless you're the test bot.
#19
#10: registry.patch queued for re-testing.
#20
Patch still had warnings about filectime/filectime due to the non-existent file. As did the file_get_contents().
Either @ is required, or a file_exists(). The @ could have better performance, but the updated patch uses file_exists() as it just seems cleaner.
#21
The last submitted patch, registry-605374-missing-files-1.patch, failed testing.
#22
My eclipse version seems to have a issue with the line endings (preferences are set to Unix), "Ensure the patch only contains unix-style line endings." Can someone re-save or make the test-bot more friendly to window users? Thx.
#23
I couldn't reproduce this issue on the latest D7 snapshot. I tried many variants of moving around modules from a directory to another.
However, if APC is active, moving a module from sites/default to sites/all causes a white screen, logs show: "[apc-error] Cannot redeclare class views_object" (i was testing with the views module). I had to restart Apache in order to solve that. It seems specific to Views though. Other modules do not cause this problem, so it may be related to how views includes files, I'll check in the views issue queue.
matt, from the Montreal Drupal7 code sprint.
#24
#25
tagging
#26
file_exists() check looks sensible to me. Interesting that bgm couldn't reproduce it though.
#27
It is just a sanity check more than anything. I hit the error using Devel to reinstall a module that was just updated with 1 less file declared. The stat & file_get_content errors were just notices / warnings as the registry tried to parse the stale file reference.
The duplicate object error described by bgm above sounds more like an duplication of the module or a duplication of a class within a module. I could not repeat the error myself by moving around core modules.
#28
I'm marking this RTBC. It's a clean fix in itself, whether the exact original bug is still reproducable or not, I've also seen this in other situations previously. Can't be triggered in testing but if it was broken tests probably wouldn't even run.
#29
If you try to add a nonexisting file to the registry, you will try to pass in FALSE for an integer because fileXtime fails and we all know that is not going to work out at all.
#30
I don't think there's a way to test this, but yikes! bad bug. :)
Committed to HEAD. Thanks!
#31
Automatically closed -- issue fixed for 2 weeks with no activity.