The file public://ctools/css was not deleted, because it does not exist.

Getting it here too anytime I enable or disable a module. Details showing up in the log is:

Type file
Date Sunday, July 31, 2011 - 2:32pm
User Webmaster
Location http://www.something.com/admin/modules/list/confirm
Referrer http://www.something.com/admin/modules
Message The file public://ctools/css was not deleted, because it does not exist.
Severity notice
Hostname XX.XX.XX.XX

Just an annoyance, but it's happening for me too.

[nvm] - I don't know why I took over this bug accidentally?

Getting the same error as #1.

Same issue here. Happens every time when I have module 'comment' disabled:

file 08/06/2011 - 20:09 The file public://ctools/css was not deleted, because...
......
system 08/06/2011 - 20:09 comment module disabled.

Same here:

Type	file
Date	Sunday, August 7, 2011 - 16:06
User	admin
Location	http://123.45.67.89/en/admin/modules/list/confirm
Referrer	http://123.45.67.89/en/admin/modules
Message	The file public://ctools/css was not deleted, because it does not exist.
Severity	notice
Hostname	123.45.67.89

Happened once when disabling the path_alias_xt module.

I still get this each time I enable/disable modules. Any thoughts?

Subscribing

I am getting this from time to time but also from time to time I get a similar message for sexybookmarks. Could this be a more general problem?

subsc

Is anyone in this thread using any kind of panel styles? Specifically rounded corners. I noticed this error in my logs and my dynamic styles are disappearing on user login as described here #1259214: Panels lose style on login if no IPE access. Has anyone in this thread noticed this?

I've had that as well and I've created and attached a patch that should resolve that issue. It always hapens when there is no directory public://ctools/css and flushing the cashe still wants to remove that directory recursively.

this seems to be a dup of http://drupal.org/node/1080626

@mefisto75 - #1080626: files/ctools/css was not deleted, because it does not exist is related, but not a dupe, as this problem is ongoing, and unrelated to the cron semaphore. It seems like the patch from #12 should fix it (I'm going to test now and see if the problem goes away after applying the patch...).

[Edit: Interestingly, I now can't reproduce the problem at all (without patch). Clearing caches doesn't do anything, and neither does enabling/disabling a module. Hrm...]

enabled a module, cleared caches, ran cron --- no error. Seems to have worked for me - still have my missing styles error but looks like this is unrelated. Good job jurgenhass.

...works for me too.

will this patch work for 7.x-1.0-rc1 version?

should - its a one line fix just search for it.

ok, applied, thanks.

Enabled a module and I dont see the error again.

works for me too

#12 works for me, too.

#12 committed.

Thanx Earl! One less patch to babysit ;)

Has this been committed yet?

Yes it has George. Actually that happened back in September 18, but latest 7.x stable (7.x-1.0-rc1) dates 2011-Jul-29. So you either use latest dev that has this in or you use 7.x-1.0-rc1 and have to apply #12. If a new stable comes out (be it 7.x-1.0-rc2 or 7.x-1.0 final) I'm sure it will be in that ;)

subscribe

@SangersDrupalDude

please don't suscribe, use the "follow" button on the upper right corner of this page

As I've already said back in #27 people wouldn't even need to subscribe/follow here if we rolled this to a stable(ish) RC2 soon.

Thanks jurgenhaas and merlinofchaos for the fix. If someone verifies that the dev version from 2011-Dec-10 containing this doesn't break anything on their site, I'd gladly try it in hopes for a cleaner log.

Offtopic: If Drupal provided a GUI option for upgrading to devs from stables (and back;) I'd go for it now in our dev environment. Downloading, unpacking and transfering the dev version and then rerolling from a backup in the worst case takes a bit more time than we look forward to spending while in order to contribute to issues that don't break user-critical functions on our sites.

I feel Drupal would deserve an even more advanced and admin-friendly module install/update/reroll/removal than WordPress already has, but currently WP's install/update/remove system is more admin-friendly out of the two. We'd test dev versions a lot more if it involved less administrative overhead time.

#12 works very nice :D very thx.

This was fixed in latest 7.x-dev, so you can use that instead. It will be included in the next stable too.

If only I could apply patches.

...sure you can Adam, all you have to do is know how to read (you obviously can) and follow well-written instructions:

Apply patches on Windows
Applying a patch manually

;)

I did not find the article on applying patches manually yesterday. Thank you.

Just added update part