Now, I am not sure whether this is a but or if someone else is or will experience but just tried drush upc rules --svnsync locally and it did something odd, and it did it twice, it may be something related to this module. My wild guess is that the fact that the rules module contains a rules module within itself is messing with the final destination of the module.

After doing drush upc rules

I end up with the previous structure removed and the new module placed on modules/rules/rules generating modules/rules/rules/rules now. After doing this I get a few warnings of file not founds/includes until the cache is rebuilt and the new module's files location can be found.

Doing it manually for now.

CommentFileSizeAuthor
#7 drush-1023120.patch4.58 KBjonhattan

Comments

hanoii’s picture

hanoii
Primary language Spanish
Location 🇦🇷UTC-3
commented

I noticed this when updating rules 1.3 -> 1.4

maddentim’s picture

maddentim commented

ditto here. drush seems to have gotten confused and put the new rules into the rules submodule directory. So trying to open the rules files was broken.

I ended up deleting the sites/all/rules folder and then "drush dl rules" and we were back in business.

As an example, drush was reporting many errors like this: (the rules.data_types.inc file was in sites/all/rules/rules/rules/rules.data_types.inc

WD php: include_once(sites/all/modules/rules/rules/rules.data_types.inc): failed to open stream: No such file[error]
or directory in /home/tim/public_html/mac/sites/all/modules/rules/rules/rules/rules.module on line 964.

drush rules! (but not in this case - pun intended!)

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented
Assigned: Unassigned » jonhattan
Priority: Normal » Major

The problem is at function: http://api.drush.ws/api/drush/commands--pm--pm.drush.inc/function/_pm_ge...

where $release['includes'] only include enabled modules for the given project. It is only 'rules' in this case. The location is rules/rules/rules.module, so the common path for all enabled modules of rules project is rules/rules.

asb’s picture

asb commented

I'm getting this "failed to open stream: No such file or directory" message on every Drush command:

$ drush up
parse_ini_file(/usr/share/drush/includes/../drush.info): failed to open stream: No such file or directory        [warning]
environment.inc:1012
Refreshing update status information ...
Done.
Update information last refreshed: Sun, 01/16/2011 - 00:45

Environment: Local development workstation, Ubuntu 10.10 (I'm using Drush also on my Debian servers where I do not experience this issue).

Any ideas?

greg.1.anderson’s picture

greg.1.anderson commented

#4 is unrelated to this issue.

asb’s picture

asb commented

It was the only open issue with the message "failed to open stream..."

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented
Status: Active » Needs review
StatusFileSize
new drush-1023120.patch4.58 KB

@asb this is a very common error message. Please open a new issue if you haven't already done it.

Patch following explanation in #3.

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented
Status: Needs review » Fixed

In case I was not clear enough in #3:

project-releases array obtained from update-info only include enabled modules for the project. This is a problem when there's only one enabled module and it is placed in a subfolder of the project. For rules 6.x:

rules
rules/rules/rules.module
rules/rules_admin/rules_admin.module
...
...

If only rules.module is enabled drush will consider the project's folder is rules/rules. If both modules were enabled, the common path is rules/. The same problem is present with examples project, ecommerce and others with a similar directory layout.

So we need all the modules in the project's update-info array. This is what this patch does. This is not a 100% fix but a 99.9%. It will fail for atypical projects (do they exist?) with a structure like mongodb-7.x-1.0-beta1:

jonhattan@larry:/tmp$ drush dl mongodb
Project mongodb (7.x-1.0-beta1) downloaded to /tmp/mongodb.                                                                                       [success]
Project mongodb contains a module named mongodb_session.
jonhattan@larry:/tmp$ find mongodb/
mongodb/
mongodb/LICENSE.txt
mongodb/mongodb_session
mongodb/mongodb_session/mongodb_session.inc
mongodb/mongodb_session/mongodb_session.module
mongodb/mongodb_session/mongodb_session.info

Note this is a 2009's release and the 7.x dev version is completely different.

More checks could be done to warrant we're picking the correct directory but I'm reluctant to include a complexity to address a usecase that has not been made manifest yet.

So committing #7.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.