i18n.inc brokes access to uploaded files, because the access is public and the module prepend the locale string before "files". So, i created this path 

i18n.inc
Index: i18n.inc
===================================================================
--- i18n.inc    (revisión: 19)
+++ i18n.inc    (copia de trabajo)
@@ -25,8 +25,15 @@
 }  
 
 function i18n_url_rewrite($type, $path, $original){
+    if (variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC) ==  FILE_DOWNLOADS_PUBLIC) {
+        $fdp=variable_get("file_directory_path","files").'/';
+        $is_file=(strpos($path,$fdp)===0);
+    } else {
+        $is_file=false;
+    }
+    //drupal_set_message("$path ".((strpos($path,$fdp)===0)?"si":"no"));
   //drupal_set_message("type=$type path=$path original=$original");
-  if ($type == 'alias' && !i18n_get_lang_prefix($path) ){
+  if ($type == 'alias' && !i18n_get_lang_prefix($path) && !$is_file){
     return $path ? i18n_get_lang() . '/'. $path : i18n_get_lang();
   } else {
     return $path;

Comments

jose reyero’s picture

jose reyero commented

This doesn't seem to happen with core modules.

File paths are not even supossed to be rewritten this way for public uploads.

So, does this happen with upload module only?. Can you provide some more details?

hexa’s picture

hexa commented

This also happens when using Audio module.
Now my audio download don't work anymore cause links look like this:
/sl/audio/download/17/MUSICALLSD+-+2+SIDES+OF+THE+SAME+COIN.mp3
instead like:
/audio/download/17/MUSICALLSD+-+2+SIDES+OF+THE+SAME+COIN.mp3

Dave Cohen’s picture

Dave Cohen commented
Version: 4.7.x-1.x-dev » 5.x-2.x-dev
Priority: Normal » Critical

I've just discoved this problem on my site as well. I think it does affect core modules, because a number of user pictures have been uploaded into en/files/pictures instead of files/pictures. Also into en/files/color (also core). And non-core files saved by bueditor, imce and upapi modules are also in en/.

And in my case this has the nasty side effect of breaking the homepage links. For example www.greatsunflower.org is OK, but www.greatsunflower.org/en is not. The reason being that /en is now a directory that is actually found, so the normal url rewriting in .htaccess is not done.

Dave Cohen’s picture

Dave Cohen commented
Priority: Critical » Normal

Wait. I just discovered the problem is not what I thought...

It seems at some point I created the en directory and put in it a symbolic link to my files. So it looks like this is my own fault.

jose reyero’s picture

jose reyero commented
Status: Active » Closed (won't fix)

So it seems for some people it is fixed.

For the rest: i18n rewriting does work for file paths, as the core upload module proves.

For other modules, create an issue for them for not using url() for files, which is conceptually wrong.