Issue status update for http://drupal.org/node/12267 Project: Drupal Version: cvs Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: stefan nagtegaal Updated by: Dries Status: patch 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. ;-) Dries Previous comments: ------------------------------------------------------------------------ October 29, 2004 - 11:37 : stefan nagtegaal The private downloads are not working properly.. How to reproduce: Goto 'http://www.your-site.com/admin/settings' and set the 'Download method' to 'Private - files are transferred by Drupal'. Now, you make a new item (blog/story/page/poll, whatever) and upload an image. You should use this image inside your post, by doing an '' inside your post, where $path is the url which is given in the 'Attachments' form-group on the submission page. (Something like 'system/files?file=$yourfile.ext') Then click 'Preview' and do not submit the node! Now, have a look what we see.. We see that the image inside the post isn't displayed properly. The image is broken. If we ask the properties of the image it points to the right location ('system/files?file=$yourfile.ext'), but isn't displayed. If we take a look at the properties of the table under the node (attached files table with 'Attachement', and 'List') we see that the attachment is pointing to something like 'http://www.frontaal-online.com/$file-system-path/$yourfile.ext' instead of the private download url.. I'm not sure how to fix this, but I think it's a bug inside function file_create_url() which could be found inside file.inc. ------------------------------------------------------------------------ October 29, 2004 - 11:51 : stefan nagtegaal Attachment: http://drupal.org/files/issues/upload-and-body.png (19.87 KB) Screenshot after upload en filling in the body.form ------------------------------------------------------------------------ October 29, 2004 - 11:52 : stefan nagtegaal Attachment: http://drupal.org/files/issues/node-preview-and-image-properties.png (78.18 KB) Now we are previewing the node with a broken image in it.. See the properties of the image, which points to another location as the 'metallic.png' hyperlink inside the 'Attachment'-table under the node preview. ------------------------------------------------------------------------ October 29, 2004 - 11:54 : stefan nagtegaal Attachment: http://drupal.org/files/issues/properties-of-metallic-link-in-attachments-ta... (53.52 KB) The properties of the 'metallic.png'-link inside the table under the node preview differs from where the source points us to.. The url inside the table works, (which is the same as in public_dowloads), but the url inside the body isn't... ------------------------------------------------------------------------ October 29, 2004 - 12:47 : stefan nagtegaal This bug is also appearing inside drupal 4.5... ------------------------------------------------------------------------ January 28, 2005 - 18:04 : walkah Attachment: http://drupal.org/files/issues/upload-private-files.patch (1.88 KB) 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). ------------------------------------------------------------------------ January 28, 2005 - 18:07 : walkah Attachment: http://drupal.org/files/issues/upload-4-5.patch (1.36 KB) here's a version for 4.5 as well ... (where the SQL wasn't broken). ------------------------------------------------------------------------ February 5, 2005 - 09:34 : Steven Isn't that SQL 'error' there to make query rewriting work? ------------------------------------------------------------------------ February 5, 2005 - 09:36 : Steven 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. ------------------------------------------------------------------------ March 13, 2005 - 20:14 : killes@www.drop.org Doesn't apply anymore. Is this still an issue? ------------------------------------------------------------------------ April 7, 2005 - 03:56 : moshe weitzman this one is marked critical. Walkah, Stefan - please comment on whether this is still a bug. ------------------------------------------------------------------------ April 8, 2005 - 02:13 : Shane Birley 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 ------------------------------------------------------------------------ April 8, 2005 - 10:38 : stefan nagtegaal This is still an issue in 4.6 RC and can still be reproduced by follwing exactly what I propose above.. While this is a longstanding bug, and with drupal 4.6 I'll changed status to patch.. Maybe some other people ould have a look at this? ------------------------------------------------------------------------ April 11, 2005 - 07:28 : chx This is the link for the file: <?php $file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())) ?> and file_create_url <?php 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.