We were successfully running 6.x-2.0-rc10. We upgraded to 6.x-2.0-rc11 yesterday. I went in and checked to make sure that the directory listings still came up ok and they did.

This morning we started getting complaints about not being able to download. I figured it was a new permission problem and went in and added download and download archive permissions to all appropriate users and saved them. However the problem persists. We're using private downloads.

At the moment I've reverted the database and returned to rc10 so we can continue operations.

It appears that there was a change in the way that files are served. Before, they appear to have been served via a URL that included a path=. Now they appear to be directly fed to Apache. I can't say that I'm happy opening up the private file area to Apache to serve the files. Am I correct in what I'm seeing and was this the intent?

Comments

Yoran’s picture

Yoran commented

Can you give a try with download manager "private" that is what you was using before I think. Perhaps I should throw a blocking form error when you choose "direct" downloads with a root outside apache realm.

Anyway the is a bug with "direct" (the one you used) leading to 404.

william haller’s picture

william haller commented

Before reverting, I tried all three available download options without changing any other parameters. I don't remember which one it defaulted to after the upgrade, but none succeeded in a download.

I'll try moving the mount point to a point inside the private file area and see what that does, but It will probably be Thursday before I can get in early and try an update without affecting operations. That would probably be a reasonable alternative. As it is in rc-10, the path is a relative path from drupal's root and private is checked.

Yoran’s picture

Yoran commented

normally you don't have to change anything to your filesystem : absolute path (outside drupal root) and 'private' download mode should work as usual. Tell me if it is the case with last dev and if it's not I should correct.

william haller’s picture

william haller commented

Did an upgrade again. Got an extra warning this time

Drupal database update
user warning: Table 'node_dir_listing_content' already exists query: CREATE TABLE node_dir_listing_content ( `nid` INT unsigned NOT NULL, `fid` INT unsigned NOT NULL auto_increment, `root` VARCHAR(255) NOT NULL, `path` VARCHAR(255) NOT NULL, PRIMARY KEY (fid), UNIQUE KEY nid_fid (nid, fid), UNIQUE KEY fid (fid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /drupal/includes/database.inc on line 550.
user warning: Duplicate column name 'root' query: ALTER TABLE node_dir_listing_content ADD `root` VARCHAR(255) DEFAULT NULL in /drupal/includes/database.mysql-common.inc on line 298.

I'm pretty sure I just got the second one the first time I did the upgrade. The tar database restore would have left the new table around producing the first error.

Path to outside the drupal tree is correct. It comes up direct on upgrade instead of private as was checked before.

Switching to private seems to be working locally here. I suspect I'd tried the private setting a couple of days ago before realizing there were new permissions. My apologies.

Yoran’s picture

Yoran commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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