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....

@SeahamPaul: Status is closed. You have to reopen the issue as Susurrus wrote in the post above yours.

@Susurrus: Same here. Without subdirectory listing cron still crashes and the node (directory listing) isn't editable. I have to change the setting in the field explore_subdirs in the filebrowser table. As long as I have a node without subdirectory listing cron runs in an error. I use the private download method in a multisite environment.

I would like to test this issue with a fresh D6 install and filebrowser next week.

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...

It works for me. With and without Allow subdirectory listings, with and without Enable private downloads, as well as with a mix of both. Cron runs properly.

But now the URLs of subdirectories uses the path_alias and I get a 404 Page not found error. There's still a general problem with the use of node/x and path_alias, imho.

With RC4 (w/o this patch) and private downloads directories and files uses node/x in the URL. IMHO, the target is the use of aliases for both directories and files if a node alias is used. First the problem with cron and subdirectory displaying must be solved. For the aliases I may post a feature request later.

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.

This just removes all uses of $path_aliases and uses 'node/NID' instead.

Only for nodes with private downloads? A node without private downloads still uses the path_alias for the file URL.

All problems should be fixed with this version

Not all. Cron issue is fixed and node/nid is used for directories. But with private downloads there is no MIME type recognition. All files will be displayed and saved as HTML. Can you reproduce this?

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.

Sorry for the long delay. The filebrowser.module from filebrowser_2.zip (2008-07-07) makes no difference to #12 (no MIME type recognition). I'm confused because version number and date of this file is older than version and date of rc4 file.

It would be very helpful if anyone other would test this file, too.

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.

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