-
Bug
-
Resolution: Fixed
-
Medium
-
5.3, 5.5.1, 5.7.1, 5.8.5, 5.8.6, 5.8.10, 5.9.4, 5.9.7
-
44
-
Severity 2 - Major
-
14
-
NOTE: This bug report is for Confluence Server. Using Confluence Cloud? See the corresponding bug report.
Step to Reproduce
- Go to a Confluence page.
- Click Tools >> Attachment
- Click Choose File button
- Attach file with the name 'İ ' ( use the İ.txt attached in this ticket)
- The following error will appear in the browser and the atlassian-confluence.log file.
java.lang.NullPointerException at com.atlassian.confluence.pages.actions.beans.AttachmentStorer.attachFiles(AttachmentStorer.java:64) Stack Trace:[hide] java.lang.NullPointerException at com.atlassian.confluence.pages.actions.beans.AttachmentStorer.attachFiles(AttachmentStorer.java:64) at com.atlassian.confluence.pages.actions.AbstractViewAttachmentsAction.execute(AbstractViewAttachmentsAction.java:104) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:168) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at
Workaround
Applicable for other non-latin languages except for İ Turkish character
- Ensure your database collation settings are able to handle international strings.
Refer to this comment for a PostgreSQL fix - Refer to this link for more information
- duplicates
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Gathering Impact
-
[CONFSERVER-31088] java.lang.NullPointerException when try to attach file with non-Latin characters
As a side effect of this issue, deleting the uploaded file from GUI also fails. For this workaround, you can use REST API instead. Please follow the following step to delete the uploaded file –
- Confirm contentid of the attachment
select * from content where pageid=<the page ID the file is attached>;
- Delete the content above with Confluence REST API
curl -v -S -u user:password -X DELETE http://<confluence-base-url>/rest/api/content/<contentid obtained by Step 1>
Hi All,
This problem was fixed in Confluence 6.7.2, we tested it.
Thank you
Regards,
Emre
A fix for this issue is now available for Confluence Server customers.
Upgrade now or check out the Release Notes to see what other issues are resolved.
Hi mkaradagli,
Thank you for you question. This fix also will solve the 'i' char issue.
Regards,
George Lipatov
Are there any update for 'i' char ? No one can access or delete these files.
Vesa Halkka
added a comment - In my case ( Finnish characters ) Postgres collating sequence was the problem - it needed to be set to UTF8 in addition to the charset. The attachments were uploaded - but couldn't be found. So I wonder is this single turkish character problem a DB bug or Confluence bug. Confluence installation should give very clear instructions about DB settings.
Vesa Halkka
added a comment - In my case ( Finnish characters ) Postgres collating sequence was the problem - it needed to be set to UTF8 in addition to the charset. The attachments were uploaded - but couldn't be found. So I wonder is this single turkish character problem a DB bug or Confluence bug. Confluence installation should give very clear instructions about DB settings. @Stephan Eisvogel +1 to you, highly accurate information. Thank you very much.
Got it working... For anyone reading this:
1. Run https://your-confluence/admin/encodingtest.action ; it has to show no error whatsoever after test.
2. For Linux: In bin/setenv.sh below export CATALINA_OPTS add
export LANG=en_US.UTF-8
export LC_CTYPE="en_US.UTF-8"
export LC_NUMERIC="en_US.UTF-8"
export LC_TIME="en_US.UTF-8"
export LC_COLLATE="en_US.UTF-8"
export LC_MONETARY="en_US.UTF-8"
export LC_MESSAGES="en_US.UTF-8"
export LC_PAPER="en_US.UTF-8"
export LC_NAME="en_US.UTF-8"
export LC_ADDRESS="en_US.UTF-8"
export LC_TELEPHONE="en_US.UTF-8"
export LC_MEASUREMENT="en_US.UTF-8"
export LC_IDENTIFICATION="en_US.UTF-8"
export LC_ALL=
to override any ANSI encoding in the Java VM towards UTF-8. Do not use any -D... system overrides, usually they are not enough or very difficult to get right concisely.
3. In /etc/default/locale add lines to look like this (this may be optional):
LANG="en_US.UTF-8"
LANGUAGE="en_US:en"
LC_ALL="en_US.UTF-8"
4. Do not use MySQL, Atlassian loves and supports Postgresql more. On Postgresql, check database with
echo -n '\l' | sudo -u postgres psql
Output of \l command should look like this:
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
---------------------------------------------------+--------------------------
confluence | confluence | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/confluence +
| confluence=CTc/confluence+ | ||||
| postgres=CTc/confluence |
Notice encoding, collate and ctype all set to UTF-8. To create a postgresl database we use
sudo -u postgres createdb -E UNICODE -T template0 -O confluence confluence.
Add grant all on database confluence to confluence; grant all on database confluence to postgres; for permission or whatever you need.
5. Check connectors in conf/server.xml that they contain URIEncoding="UTF-8" and useBodyEncodingForURI="true".
6. In /admin/viewgeneralconfig.action check that under Formatting and International Settings Encoding is set to UTF-8.
7. Restart Confluence one time.
Doing all this and your Confluence will happily speak UTF-8.
Hi eisvogel,
Apologies for not getting back to you earlier. I have tried to reproduce the issue with Confluence 5.9.5 and the filename provided using Postgres 9.4.4.1 (en_US.UTF-8) and am unable to reproduce. Hopefully the upgrade also works for you, but I see no reason why it shouldn't! 
Kind Regards,
Sami Peachey
Confluence Developer
Atlassian
Hey Sami,
thanks for getting back to me. The database is Postgres 9.3.11, lc_ctype is set to en_US.UTF-8. Server.xml in both HTTP and HTTPS connector has URIEncoding="UTF-8" and useBodyEncodingForURI="true". Oracle Java 7.80. Encoding in General Configuration is set to UTF-8.
Maybe this was fixed in between releases. I'll ask the license administrator and system administrator if they can upgrade to 5.9.5 to check this theory.
This could take a few weeks though, because of some bureaucracy required. I'll report back in any case.
Best regards!
Stephan
Dear eisvogel,
I am unable to reproduce your problem with Confluence 5.9.5 and the file provided (filename Antrieb-Übersetzung.png) through any sort of upload mechanism. What database (MySQL, Postgres, etc) are you using with Confluence?
Kind Regards,
Sami Peachey
Confluence Developer
Atlassian
This issue also happens if database and server is set up correctly, i.e. UTF-8 is used everywhere. Confluence version in this example is 5.7.4.
A user inserts a file called Antrieb-Übersetzung.png through drag-and-drop into a Chrome browser window with a page currently being edited. It does not matter if it his his personal space or a normal space. The file lands in the file system and also in the database but can't be retrieved or deleted any more. Error message right after drag&drop: "Antrieb-Übersetzung.png null" with yellow exclamation mark.
The problem appears to be similar to this person's https://answers.atlassian.com/questions/18810907/why-is-file-system-name-mangling-a-problem-when-attachments-are-stored-as-version-numbers. Also here in this instance the last encoding test fails.
If the file is uploaded as Antrieb-Uebersetzung.png everything works, but if you dare rename the attachment to Antrieb-Übersetzung.png it is gone again, 404 ("An error occurred while trying to delete the attachment. Please check the current state. The file may have been removed already.")
A bandaid fix is to go into the database, table "content", sort by "contenttype", look for "ATTACHMENT" that has the offending name and just rename the value in "title" to something latin-only. Restart Confluence. If you are not the text console guy, try HeidiSQL on Windows, that has a GUI (very stable for MySQL, not so much for Postgresql). At least you will regain control over those attachments.
Looking closer, the error happens in JAR confluence-drag-and-drop-5.7.4.jar in UploadAction.class in the method getDetails. Here presumably the call to attachment.getId() fails (returns NULL for unknown reasons), hence the NullPointerException caused by String.valueOf(null) in the backtrace. I will try to upload a debug trace and the offending PNG-file to this ticket.
On a closing note, you may be interested to know that in Germany a locale bug such as this will make you liable under Sachmängelhaftung by law, and if this isn't fixed within a reasonable amount of time, every Confluence customer is eligible for a refund. I say this because I observe the age of this ticket, the responses from Atlassian so far, and because I have seen the ignoring of other similarly grave tickets. Hiding the People directory and users from each other comes to mind. At the end of the day customers do not care, if Atlassian developers think that implementing the new features du jour is much hipper than solving long-standing grave defects, while management's occupation is counting money instead of steering product maintenance.
Mattias Flodin
added a comment - See also the paragraph here that Atlassian linked for me. Workaround
With the aid of Atlassian support we have worked around this problem on our site. It seems the reason for the failure we were seeing with Swedish ÅÄÖ is due to Confluence performing case normalization of attachment names on the database end. With PostgreSQL this does not work if the database's LC_CTYPE (and possibly also LC_COLLATE) settings are incompatible with Swedish (e.g. 'C' or 'POSIX'), since all such characters will be ignored during case normalization.
If you look at the database CREATE script in pgAdmin and it looks something like this:
CREATE DATABASE confluence WITH OWNER = confluenceuser ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'C' LC_CTYPE = 'C' CONNECTION LIMIT = -1;
then you need to change it into something like:
CREATE DATABASE confluence WITH OWNER = confluenceuser ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'Swedish_Sweden.1252' LC_CTYPE = 'Swedish_Sweden.1252' CONNECTION LIMIT = -1;
Obviously the character type should correspond to your country, language and code page. If you did get LC_CTYPE='C' originally then it is likely that your template database was created that way when you installed PostgreSQL, and it will refuse to create a new database that violates that unless you use template0, i.e.:
CREATE DATABASE confluence WITH OWNER = confluenceuser ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'Swedish_Sweden.1252' LC_CTYPE = 'Swedish_Sweden.1252' CONNECTION LIMIT = -1 TEMPLATE=template0;
PostgreSQL does not allow you to change these settings on the fly, so you will need to dump the database and load it to a new database created in the proper way, using pg_dump and pg_restore. We used this to dump the database:
pg_dump -U confluenceuser -b -E utf8 -F d -o -w --file c:\temp\confluence_backup confluence
And this to restore it:
psql -U postgres -c "ALTER USER confluenceuser WITH SUPERUSER" postgres pg_restore -U confluenceuser -d confluence c:\temp\confluence_backup psql -U postgres -c "ALTER USER confluenceuser WITH NOSUPERUSER" postgres
The part about temporarily turning confluenceuser into a superuser is there to avoid security-related complaints about PosgreSQL extensions. I think it's not really required but just to be sure.
The Turkish dotted i is special in that its capital case is different from all other Western languages, so I'm unsure if this workaround will work properly in that locale. At the very least, you will not be able to get proper handling of both Turkish and non-Turkish documents in the same database at the same time. If anyone would like to test this it would be interesting to hear the result.
PS. Sorry for all the notification email spam, this was a rather lengthy post so I ended up fixing a bunch of errors that I didn't notice until later on.
Mattias Flodin
added a comment - - edited Workaround
With the aid of Atlassian support we have worked around this problem on our site. It seems the reason for the failure we were seeing with Swedish ÅÄÖ is due to Confluence performing case normalization of attachment names on the database end. With PostgreSQL this does not work if the database's LC_CTYPE (and possibly also LC_COLLATE) settings are incompatible with Swedish (e.g. 'C' or 'POSIX'), since all such characters will be ignored during case normalization.
If you look at the database CREATE script in pgAdmin and it looks something like this:
CREATE DATABASE confluence
WITH OWNER = confluenceuser
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = ' C '
LC_CTYPE = ' C '
CONNECTION LIMIT = -1;
then you need to change it into something like:
CREATE DATABASE confluence
WITH OWNER = confluenceuser
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'Swedish_Sweden.1252'
LC_CTYPE = 'Swedish_Sweden.1252'
CONNECTION LIMIT = -1;
Obviously the character type should correspond to your country, language and code page. If you did get LC_CTYPE='C' originally then it is likely that your template database was created that way when you installed PostgreSQL, and it will refuse to create a new database that violates that unless you use template0, i.e.:
CREATE DATABASE confluence
WITH OWNER = confluenceuser
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'Swedish_Sweden.1252'
LC_CTYPE = 'Swedish_Sweden.1252'
CONNECTION LIMIT = -1
TEMPLATE =template0;
PostgreSQL does not allow you to change these settings on the fly, so you will need to dump the database and load it to a new database created in the proper way, using pg_dump and pg_restore. We used this to dump the database:
pg_dump -U confluenceuser -b -E utf8 -F d -o -w --file c:\temp\confluence_backup confluence
And this to restore it:
psql -U postgres -c "ALTER USER confluenceuser WITH SUPERUSER" postgres
pg_restore -U confluenceuser -d confluence c:\temp\confluence_backup
psql -U postgres -c "ALTER USER confluenceuser WITH NOSUPERUSER" postgres
The part about temporarily turning confluenceuser into a superuser is there to avoid security-related complaints about PosgreSQL extensions. I think it's not really required but just to be sure.
The Turkish dotted i is special in that its capital case is different from all other Western languages, so I'm unsure if this workaround will work properly in that locale. At the very least, you will not be able to get proper handling of both Turkish and non-Turkish documents in the same database at the same time. If anyone would like to test this it would be interesting to hear the result.
PS. Sorry for all the notification email spam, this was a rather lengthy post so I ended up fixing a bunch of errors that I didn't notice until later on. Mattias Flodin
added a comment - This is not just non-Latin characters. I am seeing the same issue with capital ÅÄÖ in latin-1. Consequently I believe this affects any non English-speaking country in the world. All our documentation is in Swedish and this is preventing us from migrating it to Confluence.
Further, the problem is compounded by the fact that if you use the drag/drop handler (confluence.plugins.dragdrop.UploadAction), then an entry is created in the database and is not rolled back after the failure occurs. So every time a user uploads a file with non-ASCII characters you will get an attachment link that leads to a 404. If you try to delete it, you get this error:
An error occurred while trying to delete the attachment. Please check the current state. The file may have been removed already.
It is impossible to delete the attachment without manually going into the database and deleting the appropriate rows. I am not comfortable doing this many times as every time increases the risk of making a mistake and corrupting the database.
I realize that you may have many high-priority issues on your backlog, but this seems to me like low-hanging fruit. It is not a difficult issue to reproduce and I suspect that stepping through the code would reveal a simple mistake in case normalization.
Mattias Flodin
added a comment - This is not just non-Latin characters. I am seeing the same issue with capital ÅÄÖ in latin-1. Consequently I believe this affects any non English-speaking country in the world. All our documentation is in Swedish and this is preventing us from migrating it to Confluence.
Further, the problem is compounded by the fact that if you use the drag/drop handler (confluence.plugins.dragdrop.UploadAction), then an entry is created in the database and is not rolled back after the failure occurs. So every time a user uploads a file with non-ASCII characters you will get an attachment link that leads to a 404. If you try to delete it, you get this error:
An error occurred while trying to delete the attachment. Please check the current state. The file may have been removed already.
It is impossible to delete the attachment without manually going into the database and deleting the appropriate rows. I am not comfortable doing this many times as every time increases the risk of making a mistake and corrupting the database.
I realize that you may have many high-priority issues on your backlog, but this seems to me like low-hanging fruit. It is not a difficult issue to reproduce and I suspect that stepping through the code would reveal a simple mistake in case normalization. 
Mehmet Ali Aydın
added a comment - @fadenb, I think the impact of the issue is not described well. Atlassian has no idea about how this impact their customers. Here the impact of issue for my company:
- We are not able to download old files uploaded before an upgrade (no workaround)
- We have to rename files before upload.
- We can not open/create/edit/delete subpages if parent's summary contains a non-Latin character
- We have to tell to users Confluence is buggy and teach them #1, #2 and #3
Even 21 customer voted for this issue and it is not possible to use some functionality in my language this is issue is a minor issue for 2 years, because Confluence home page returns 200.
Mehmet Ali Aydın
added a comment - @fadenb, I think the impact of the issue is not described well. Atlassian has no idea about how this impact their customers. Here the impact of issue for my company:
We are not able to download old files uploaded before an upgrade (no workaround)
We have to rename files before upload.
We can not open/create/edit/delete subpages if parent's summary contains a non-Latin character
We have to tell to users Confluence is buggy and teach them #1, #2 and #3
Even 21 customer voted for this issue and it is not possible to use some functionality in my language this is issue is a minor issue for 2 years, because Confluence home page returns 200. 
Tristan Helmich
added a comment - mtran@atlassian.com: Why was the priority changed to minor?
This issue is still affecting all our users and there is no feasible workaround for this issue!
Tristan Helmich
added a comment - mtran@atlassian.com : Why was the priority changed to minor?
This issue is still affecting all our users and there is no feasible workaround for this issue! 
Ilya Matveychikov
added a comment - +1 for the problem with Russian names, for example "СЕНТЯБРЬ-2015.jpg"
2015-09-08 14:51:07,766 ERROR [http-nio-8090-exec-6] [confluence.plugins.dragdrop.UploadAction] execute Failed to save file.
Ilya Matveychikov
added a comment - +1 for the problem with Russian names, for example "СЕНТЯБРЬ-2015.jpg"
2015-09-08 14:51:07,766 ERROR [http-nio-8090-exec-6] [confluence.plugins.dragdrop.UploadAction] execute Failed to save file. Tristan Helmich
added a comment - This is also affecting us with version 5.7.1.
What is the status of this issue. Is it actively being worked on?
Tristan Helmich
added a comment - This is also affecting us with version 5.7.1.
What is the status of this issue. Is it actively being worked on? 
Karel Hala
added a comment - This issue occures on linux as well.
Here in Czech Republic we use characters like č,ř and other on daily baisis and these upper case characters in filename cause null pointer exception when uploading file.
Production server is SUSE Linux Enterprise Server 12
user.language is set to en
user.country is set to US
server file encoding is set to UTF-8
I am NOT able to reproduce this error on local machine which is running on windows 7 with cs_CZ (file encoding 1250) and neither on test server which is running on linux (CentOS release 5.10) with en_US.
Karel Hala
added a comment - This issue occures on linux as well.
Here in Czech Republic we use characters like č,ř and other on daily baisis and these upper case characters in filename cause null pointer exception when uploading file.
Production server is SUSE Linux Enterprise Server 12
user.language is set to en
user.country is set to US
server file encoding is set to UTF-8
I am NOT able to reproduce this error on local machine which is running on windows 7 with cs_CZ (file encoding 1250) and neither on test server which is running on linux (CentOS release 5.10) with en_US. 
Olga Miras
added a comment - We also have this on Linux.. I dont think it is a Windows related issue
Olga Miras
added a comment - We also have this on Linux.. I dont think it is a Windows related issue Mehmet Ali Aydın
added a comment - sdudley thanks for info, we already have plans to move linux machines. I will test it as soon as possible.
Mehmet Ali Aydın
added a comment - sdudley thanks for info, we already have plans to move linux machines. I will test it as soon as possible. mehmet.aydin, I am able to upload the file using all methods correctly. My tests were on Linux with an ext3 case-sensitive filesystem, with the system language also set to English. I wonder if it could be a Windows-related issue?
Mehmet Ali Aydın
added a comment - Hi @Scott,
Can you please share your settings to compare the differences.
Thanks
1- Windows Server 2008 R2 SP1 / Confluence 5.5
2- NTFS / Not case sensitive (I guess it is optional for NTFS)
3- Tools->Attachments : Upload failed
Attachments Macro via browse : I was not able to find a browse button to upload files :S
Insert->Attachment : Can not select a fıle whıch contains İ character (This must be another bug)
Attachments Macro via drag and drop : There is neither error on console log nor request to server
4- System Language : en
Mehmet Ali Aydın
added a comment - Hi @Scott,
Can you please share your settings to compare the differences.
Thanks
1- Windows Server 2008 R2 SP1 / Confluence 5.5
2- NTFS / Not case sensitive (I guess it is optional for NTFS)
3- Tools->Attachments : Upload failed
Attachments Macro via browse : I was not able to find a browse button to upload files :S
Insert->Attachment : Can not select a fıle whıch contains İ character (This must be another bug)
Attachments Macro via drag and drop : There is neither error on console log nor request to server
4- System Language : en
I was able to attach the above İ.txt to my Confluence 5.5.2 system without problems. This makes me wonder if it might be a configuration or environment-related issue. I don't work for Atlassian, but to see if there are any commonalities with the people who are having problems (possibly helping you discover what could be changed to make it work!), it would be interesting if a few people could post:
1- What OS are you using?
2- What filesystem are you using? And, importantly, is it a case-sensitive filesystem?
3- Exactly how are you attaching the file? (Tools->Attachments, Attachments Macro via browse, Attachments Macro via drag and drop, Insert->Attachment within the editor, etc)
4- What is the "System Language" on your admin System Info page?
I ask about point #3 because another bug (CONF-31883) suggests that the method used to attach the file could be relevant.
Alper Can
added a comment - yes also priority still looking Minor. this issue craeated 08/Oct/13 and still can not resolve but still minor it shows atlassian dont care except English Language. i am start thinking leave from confluence platform...
Alper Can
added a comment - yes also priority still looking Minor. this issue craeated 08/Oct/13 and still can not resolve but still minor it shows atlassian dont care except English Language. i am start thinking leave from confluence platform... Mehmet Ali Aydın
added a comment - @alper.can , atlassian don't really care about us :/ while we pay for support...
Mehmet Ali Aydın
added a comment - @alper.can , atlassian don't really care about us :/ while we pay for support... Same for German and probably most non-English languages. Luckily, I only get reports every once in a while, but I'm actually surprised I don't get reports on a daily base.
Alper Can
added a comment - btw it is not a minor problem. it is a important problem becouse a lot of people use "İ" charecter in Turkey. My customer and my personel ask it everyday since May.
Alper Can
added a comment - btw it is not a minor problem. it is a important problem becouse a lot of people use "İ" charecter in Turkey. My customer and my personel ask it everyday since May. Alper Can
added a comment - hi, @steve haffenden
we are want resolve this problem but we are waiting since MAY 14. Do you think resolve this problem? Please resolve it. some users used "İ" charecter in confluence and they are recive error and they are can not use that have "İ" charecter files.
Alper Can
added a comment - hi, @steve haffenden
we are want resolve this problem but we are waiting since MAY 14. Do you think resolve this problem? Please resolve it. some users used "İ" charecter in confluence and they are recive error and they are can not use that have "İ" charecter files. Hi atlassian155
I believe that the issue regarding the accessing of existing files is different from the issue of not being able to attach files in the first place. As such I've create CONF-34461 to track this separately.
Regards
Steve Haffenden
Confluence Bugmaster
Atlassian
Hi Steve,
Can you please explain the simple workaround for the hundreds of existing attachments which we cannot access after upgrade?
We would like to apply as soon as as possible as it impacts day to day work
Hi atlassian155
I believe that the priority of this issue is correct. The technical impact is relatively low and there is a simple workaround. Please bear in mind that priority is only an indication of the technical impact of an issue and is not the only factor that we consider when prioritising issues onto our backlog.
Regards
Steve Haffenden
Confluence Bugmaster
Atlassian
Could you please increase the priority of this issue. As stated in the linked issue CONF-34371 this issue does not only appear while attaching, also causes problem for the existing attachments. The attachments that contains "İ" cannot be accessed.
This is not a minor issue. After upgrading to 5.5 old attachments cannot be found. In fact you cannot do anything with them at all.
This problem had been corrected previously. Somehow it resurrected
I can also can reproduce it with the filename "Übersicht.xlsx". I couldn't yet pinpoint the encoding of the umlaut in there but I'd assume there is an issue with anything that is neither ASCII nor Unicode.
Mehmet Ali Aydın
added a comment - This problem also causes "Page not found" error for already uploaded files with "İ" character (this case is for someone who upgraded from earlier versions of confluence).
Mehmet Ali Aydın
added a comment - This problem also causes "Page not found" error for already uploaded files with "İ" character (this case is for someone who upgraded from earlier versions of confluence).
higuchi@ricksoft.jpさん
I'm glad to hear that the information is helpful.
Thanks.