Apologies for the quick post, am hectic today.

Just updated a site to RC1 from beta 6, and there seems to be a new problem with private file uploads, and its possibly to do with recent path changes and the use of base path etc. Anyway, the link for a private file upload is now, for example:

http://...co.uk/system/files/galvatron.png

which doesn't work), instead of (the correct?):

http://...co.uk/system/files?file=galvatron.png

Again, apologies for brief post, will check into this when I get some time.

Could be a critical problem for those sites using private file downloads.

Comments

pfaocle’s picture

pfaocle
He/Him
Primary language English
commented

Culprit?

http://cvs.drupal.org/viewcvs/drupal/drupal/modules/upload.module?r1=1.8...

chx’s picture

chx commented
Priority: Normal » Critical

Indeed another updater is needed. I vote for merging this into the base path updater -- no need to iterate all nodes twice. I think the benefits are much bigger than the disadvantages.

dopry’s picture

dopry commented

file_download was also updated to work with both the old new private files url. &file= should override and path following system files, although a regex to convert them would be great. I'll try to work on one today.

dopry’s picture

dopry commented

I cannot reproduce. I setup a 4.6.6 site with private files and private tmp dir(outside of doc root).

I added several nodes with attached files. Used both absolution and relative urls to display the files in the node body.

Upgraded to 4.7 rc, ran update.php and everything still worked fine. I can use both old style(/system/files?file=path/file.ext) and new style(/system/files/path/file.ext) private file urls without a problem.

What I did discover....

There is some possibility of files table index corruption.. (I'm not sure if its normal or because my files table is some almalgamtion of the drupal.org files table and a few others I combined to test different cases for the update_173(file table and file revisions normalization update). After one test upgrade I was getting druplicate fid errors. Others updates with a cleaner files table did not have the issues.

private file previews do not work in 4.6.6.

Synopsis.
I will keep the legacy ?file= handler for now. I will try to get a patch rolled that works with the existing update_178 to update the urls tommorrow.

killes@www.drop.org’s picture

killes@www.drop.org commented

I am waiting for feedback from Paul, but it looks to me as if it weren't reproducible and thus not really critical.

pfaocle’s picture

pfaocle
He/Him
Primary language English
commented
Priority: Critical » Normal

Just taking a look now, but I think this is a problem on our side - we use a lightTPD web server, and so don't use Drupal's .htaccess for rewrite rules - our rewrite rules may need tweaking for the clean URL version of the file path.

Kind of confirmed by simply switching clean URLs off on the problem site... more soon.

pfaocle’s picture

pfaocle
He/Him
Primary language English
commented
Status: Active » Fixed

Bingo. Needed to add in an extra line for this new clean URL (domain.com/system/files/blah.jpg). For those interested:

url.rewrite-final = (
    "^/system/test/(.*)$" => "/index.php?q=system/test/$1",
    "^/system/files/(.*)$" => "/index.php?q=system/files/$1",
    "^/([^.?]*)\?(.*)$" => "/index.php?q=$1&$2",
    "^/([^.?]*)$" => "/index.php?q=$1",
    "^/rss.xml$" => "/index.php?q=rss.xml",
    "^/search/node/(.*)$" => "/index.php?q=search/node/$1"
  )

Marking fixed. Sorry about the oversight.

(@dopry: those other problems you mention should perhaps have new issues created now?)

dopry’s picture

dopry commented

I'm not backporting the preview fix to 4.6.6 upload module had change to much to make that feature easily backportable for me.

The index corruption is an odd ball... I need to figure out why, and need more example cases to reproduce. It may be a missing autoincrement on {files}.fid, but I only experienced it in on of about 20 upgrade tests with a very badly corrupted files table. I'll investigate further.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)