25 November 2010, 16:35

Jeff,

You should be able to confirm if cron is breaking your site by creating a new view containing just a new folder of files (don't use an exisiting folder, just create one at top level and drop a couple of files into it). If you can download the files in that view OK straight after creation, and then come back to it after rebuild_artefact_parent_complete runs to find the 'access denied' errors, then that function is breaking your site.

The explanation you gave earlier in this thread points to this being the problem. Can you confirm this at least?

26 November 2010, 17:55

Steve:
       Cron is not breaking things, but it's not fixing things either. A folder dropped into a view still allows access to its contents hours later (I still have "rebuild_artefact_parent_cache_complete" running every 5 mnutes). A subfolder within a folder still throws the "Access denied" error from the start, and still after hours.

28 November 2010, 21:56

Jeff, I can't reproduce your error on my setup (LAMP). I wonder if this is something unique to your particular setup...

For one of the artefacts that is in /home/parentfolder/subfolder, ascertain its ID (from its URL in the view) and run the following query on your database

SELECT * FROM `artefact_parent_cache` where artefact = ID

When I do this I get back one entry: with the 'parent' being the ID of the subfolder. This corresponds with the id in the URL you see when you mouseover the subfolder name in My Files. Then try:

SELECT * FROM `artefact_parent_cache` where artefact = subfolderID

What do you get back? You should get an entry with the 'parent' being the ID of the parentfolder. If you're not getting this then for some reason Mahara isn't writing that entry to the database, and that's what's breaking your site.

I suggest you make sure the bug is reported at https://bugs.launchpad.net/mahara. I can't see this bug in the list, and I'd consider it to be at least of medium importance.

29 November 2010, 8:03

Steve:
      Greatly appreciate you working with me on this. If this is a bug, from my perspective, it's a lot more important than "medium," since I have one one of my larger schools about to bail on using the entire system because of it. But then, that's just me...*sigh*...
      First suggested query returns the correct subfolder #, with "dirty" marked as 1.Second suggested query returns the correct parent folder #, also with "dirty" marked as 1. Error message remains.
       I went back to one of the earliest errors I found, and ran queries against that, in the same sequence. All #'s seem to be there, but "dirty" marked as 0. Access denied still there.
       I'm going to spend some time this morning seeing if I can get cron to spit out the process log somewhere where I can find it.

                  Jeff

29 November 2010, 16:22

Jeff, I don't know what else to suggest from here, sorry. I think the developers really need to step back in with their expertise as this is obviously affecting more than one site, and as you say, it's a serious issue.

Just out of interest: was your site working fine and then developed this problem, or could it have been happening since installation?

23 November 2010, 22:56

We probably need to write rebuild_artefact_parent_cache_complete to use less memory.  It pulls *all* the ids out of the artefact table and does a bunch of recursive calls to a function called artefact_get_parents_for_cache for each one.

This might be the same as the problem reported here: https://bugs.launchpad.net/mahara/+bug/680710

21 November 2010, 17:10

Any news on this access denied problem?

I'm noticing the same thing from users on my site. What I've also found is that a view I created myself, containing a folder of files for download, was fine when it was first created. But now, several days later even when I'm logged in and go to download one of the files in that view, I'm being given errors like:

Access Denied
You do not have access to view this page

Artefact 22 not in View 10508

Any clues? This is really weird. I've checked my cron table and all the dates/times are up-to-date.

21 November 2010, 21:17

Steve:
       You can see the thread...it seems to be ongoing. I'm actually pretty unhappy that folks in my district are trying to use this system as if it were just a network server, which exacerbates this problem, but I still wish it worked.

26 November 2010, 6:56

I'm also a bit dissapointed. Ik tried everything in the tread, but still got the massage access denied.

26 November 2010, 9:35

I wish I'd seen this thread sooner it would have saved me some time in tracking this down for us, I only got to the bottom of it last week. We were having exactly the same problem and it was caused by rebuild_artefact_parent_cache_complete() running out of memory and dropping some of the newest artefacts.

I cured it by altering the raise_memory_limit() in cron.php, raising it to 256M fixed the problem for us.