Private downloads aren't working

here's a small patch to fix. basically the custom url rewriting (for when files haven't been yet saved to their final location) wasn't taking into account FILE_DOWNLOADS_PRIVATE. this fixes that

(oh, and it also fixes an sql error in upload_download as well).

here's a version for 4.5 as well ... (where the SQL wasn't broken).

Isn't that SQL 'error' there to make query rewriting work?

By the way, I still think we should alter the autop filter so it uses & rather than making this one use a numbered entity. 'amp' is the most common notation out there, and it's shorter too.

Doesn't apply anymore. Is this still an issue?

this one is marked critical. Walkah, Stefan - please comment on whether this is still a bug.

This might point some people in the correct direction. It isn't completely the same issue, but related, I would think and might need to be fixed prior.

http://drupal.org/node/17364

This is the link for the file:

$file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path()))

and file_create_url

  case FILE_DOWNLOADS_PRIVATE:
      return url('system/files', 'file='. $path);

basically, the preview link and the final link is very, very differnt in private case: if it's a preview (no fid) you get a URL without a query unlike in the final stage. To say the least, it's not trivial to fix.

As Dries said: private file downloads need to be rewritten.

On a related note yet slightly off-topic, someone I know is looking into using Drupal for a high-traffic site. They'll have at least 5 front-end servers running Drupal on top of a single database. Most of their users use avatars and they wonder how to go about this. If user A uploads his avatar to server 1, it must become immediately visible on all 5 servers. Using rsync did not sound like a solution, as the other servers would have spawned a lot of 404s by the time the avatars are synced. The obvious solution is to store the avatars in the database, but Drupal doesn't allow this and if it would, it would have a significant performance impact given there are pages with 100+ avatars.

As it stands Drupal is pretty much written for single-server machines. But as bigger projects adopt Drupal, with more complex setups, efficient file handling/uploading might become an issue. It might be a good idea to think this true a little while rewriting parts of file.inc.

It's an interesting problem so that should be fun. ;-)

I've just uplaoded an image (using image.module) to a 4.6.2 site and there was a thumbnail shown on the preview . I suppose this got somehow fixed.