Redmine

FTR: #18928#note-5.

Can you re-install redmine with the newer version and just copy the file directory over while using the same database?

So, I reinstalled Redmine 2.6.1
Now:
sh: 1: darcs: not found
sh: 1: hg: not found
sh: 1: cvs: not found
sh: 1: bzr: not found
Environment:
Redmine version 2.6.1.stable
Ruby version 1.9.3-p551 (2014-11-13) [i686-linux]
Rails version 3.2.21
Environment production
Database adapter Mysql2
SCM:
Subversion 1.6.17
Git 1.7.9.5
Filesystem
Redmine plugins:
no plugin installed

I copied the file directory, but the behaviour the same -
in links: "attachments" path
in files on file system: "files" path
It's too bad((

ok.. well all of my files, whether I attach them to issues or upload them to the "Files" section all use the ".../attachments/..." url to access the files.

So im not sure why or where you are trying to find a /files/ path; as long as you are using the same database, I think it should be working fine.

The URL that redmine uses arent analogous to a file system.
/attachments/something does not mean the files are stored in the attachments folder.
/issues/something does not mean the issues are in the issues folder.
etc.

I dont think you should expect to find things in the directories according to what the URL says.

It's more clearly.
O, I understand. The problem is that files named using Cyrillic. I see, that other files are available with "attachments" links. So, problem with such files. How I can resolve it?

The topic similar: Redmine Git with Cyrillic file names

not quite sure what you mean.
are your filenames originally in Cyrillic?

if its a problem with the characters, then it could be a character set issue of some sort... but the database is UTF i believe. so i think it should be able to handle it fine... unsure

Yes, my filenames originally in Cyrillic and database is UTF. And I can't download it, I get 404 error for it.

It's very strange behaviour, please, help me with it.
Posibly, passenger is incorrect?

So, I use passenger with nginx. If I try download ciryllic file, I get error:
404 Not Found
nginx/1.6.2
and error log:
015/02/03 15:45:16 [error] 30885#0: *8516 open() "/usr/share/redmine/public/attachments/download/2/Отчет на 25.09.13 - 15.12.txt" failed (2: No such file or directory),

Have anyone ideas?

Only thing I can think of is make sure the database can handle it (looks like its fine) and make sure the code can handle it (not sure where to start) but i feel like maybe Ruby is not handling it correctly??

this is kind of old and not sure if it applies, but its a quick google search result.
http://snippets.aktagon.com/snippets/367-how-to-fix-bad-uri-is-not-uri-

I was able to test with IE8. IE8 links are corret, it seems
http://tasks.mydomen.ru/attachments/download/6/%D0%A2%D0%97%20%D0%BD%D0%B0%20%D1%80%D0%B5%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD%20v.0.0.doc
I found that my previous installation uploaded files with non-ciryllic names can be downloaded correct.
But newly added ANY files cannotbe downloaded. Files are exists physically.
And I have no any more ideas what wrong.
Only one solution - install redmine with clear database, but I need to save old data and use it. Another solution - use older version of redmine, but now I have not old backup.
Please, help.

For example, I uploaded file

200_300_SUTEEV.jpg

 http://tasks.mydomen.ru/attachments/download/24/200_300_SUTEEV.jpg

404 Not Found
nginx/1.6.2

Started POST "/uploads.js?attachment_id=1&filename=200_300_SUTEEV.jpg" for 192.168.234.220 at 2015-02-09 12:29:32 +0300
Processing by AttachmentsController#upload as JS
  Parameters: {"attachment_id"=>"1", "filename"=>"200_300_SUTEEV.jpg"}
  Current user: admin (id=1)
Saving attachment '/usr/share/redmine/files/2015/02/150209122932_200_300_SUTEEV.jpg' (58698 bytes)
  Rendered attachments/upload.js.erb (0.5ms)
Completed 200 OK in 14.3ms (Views: 1.5ms | ActiveRecord: 6.2ms)
Started POST "/projects/s_ru/files" for 192.168.234.220 at 2015-02-09 12:29:34 +0300
Processing by FilesController#create as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"xxxxxxxx", "attachments"=>{"1"=>{"filename"=>"200_300_SUTEEV.jpg", "description"=>"", "token"=>"yyyyyyy"}}, "commit"=>"Добавить", "project_id"=>"s_ru"}
  Current user: admin (id=1)
  Rendered mailer/attachments_added.text.erb within layouts/mailer (0.1ms)
  Rendered mailer/attachments_added.html.erb within layouts/mailer (0.1ms)

A found also that I have no problem with non-image and non-ciryllic files. I can upload it and download correctly.

Well looks like the log shows that its allowing you to upload files successfully.

What happens when you try to download?

I didn't quite fully understand what you mean when you said you tested with IE8 and it worked.

If you are considering re-installation of Redmine with a New Database, then you can make a backup copy of the /files/ directory of redmine and when you have the new Redmine and new database, you can re-upload all the files from the /files/ directory back into Redmine.

When I try to download, all right. Files shown as attached, but I can't download it, except non-image and non-ciryllic files.
What about IE8, I was wrong. The behaviour not browser-depended.
I don't know the reason of such situation.
I did install new redmine and after that updated the database and use old files, but it doesn't work. All files now on the disk and file system.

Please, say, how I can debug the remote redmine to fix this issue? I really need it.

My nginx configuration:

server {
        listen 192.168.xxx.xxx:80;
        server_name xxx.xxx.ru;
        access_log /var/log/nginx.access_log;
        location ~*\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|xml|docx|xlsx)$ {
                root  /usr/share/redmine/public;
                index index.html index.php;
                access_log off;
                expires 30d;
        }
        location ~/\.ht {
                deny all;
        }
    root /usr/share/redmine/public;
        passenger_enabled on;
}

I found the same issue, and issue is fixed now.
http://www.redmine.org/issues/13564
Thanks.