Cron vs. Subdirectory displaying

I can't seem to reproduce this on my end. Have you disable all non-core modules besides filebrowser and tried it then? Also, what are the settings for the various directory listings you've created? In 6.x-2.x there's no global "allow subdirectory listings" setting and it's per node.

Can you update to the newest version and reopen if this problem persists?

Same issue for me (now running on rc4).

Ran cron.php from the URL line and got one of the downloads page with error message: "You're not allowed to view xxxFilesSection/DatabaseUpdatesnode." but was signed in as site administrator.

However that node page still listed as normal.

HIH....

Alright, so I figured out the problem and I was able to reproduce it on my end. Not really sure if my solution was elegant, but try out the module I have attached. It shouldn't exhibit the problem.

Also, this is for rc4. Please update to that version and then replace the module with this one.

Here's one that's a little cleaner...

This just removes all uses of $path_aliases and uses 'node/NID' instead. I keep forgetting that URL aliases don't work like menu items so you can't pass additional arguments using standard URL directory syntax. Try this out, though, worked fine for me.

All problems should be fixed with this version, though the previous ones I posted should've fixed the cron issue.

I found another instance of aliasing being used, but that was only during an error. The URL for files is generated like this:
$node->private_downloads == '1'?url($_GET['q'] . '/' . $file):$base_url . '/' . $full_path, which doesn't use the path_alias ever. Even using the $_GET array returns the non-aliases node path.

I've looked into MIME types before and it's a very tricky business if you can't rely of a file upload to capture the MIME types. PHP really sucks at determining this information consistently across multiple operating systems. I've attempted to determine the MIME type in two different ways through PHP, but it doesn't work on my machine using WAMP. Try it out and let me know if it works.

The MIME type issue is not something I'm going to work hard to fix, as my patch in #13 is as good as it's going to get. There's no reliable way to get MIME types for files if you aren't reading the MIME type from a file as it's being uploaded.

Since that is the case and private downloads don't seem to work without MIME detection, I may just need to remove that feature altogether unless someone steps up with a solution.

As of right now the code looks good for fixing various issues excluding the MIME detection. I'm going to commit this code and deal with MIME issues in a separate one.

I have committed the MIME-detecting code and it works on my install over here. Even when it doesn't work however, the fallback still forces a download with a generic MIME-type that should force the OS to figure it out itself. I'll be releasing a new RC, but the nightly should have these changes also.

I still see the same symptoms with drupal 6.6 and filebrowser 6.x-2.0-rc5, so I'm reopening this issue. Please let me know if I should submit a new one instead.

Thanks,
Stefan

I have subdirectory listings enabled (and I can't disable them). That's the only difference I can see.
Is there any way to debug this ?

Thanks,
Stefan

The posted fix in the dev version isn't actually correct. The problem has to do with this module trying to detect the path based on the query string. This is incorrect for a couple reasons:

1) This module is detecting in case-sensitive mode whereas drupal is case in-sensitive.
2) It assumes nobody is going to use path aliases for subdirectories.
3) Cron doesn't pass off the query string.

The correct solution is to use drupal's arg() function. This already takes aliases into consideration in case insensitive mode and gives consistent results. It also works properly in cron. Attached is the patch to fix this in 6.x-2.0-rc5.

For additional clarification: The reason cron runs into this issue and only some of the time is because it's loading for the search results. After the page may have been indexed, it won't attempt to reload the page. To better reproduce it before my patch, tell Drupal to reindex your site.

Sorry, my fix didn't support multiple directory levels. Here's a revised patch.

I get the same error after patch. Any other thoughts?

You're not allowed to view /status/run-cron.
-----------------------------------------------------------
Update:
It's working now. It must have been indexing... Thanks for the patch!